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ABSTRACT 



A systems analysis of a comouter system to suooort the STAR 
war aaming model is oresented. The war game is described 
ana the user's objectives are defined. Four conceptual 
methods for implementing the user’s objectives are oresented 

and a preferred solution is chosen. The characteristics of 

/ 

the preferred solution that are necessary to meet the user’s 
objectives are describee. Further software needed to 
implement the objectives is briefly discussed. The code for 
the current model is analyzed and a summary presented. 
Conclusions from this systems analysis are derived and 
future research areas are identified. 
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I. INTRODUCTION 



A computer simulation is the representation of a 
mathematical model in a manner that allows the user to 
examine the system beinq modeled and gain further insight 
into the inner workings of. the system. Typically, 
simulations fall into five classes: the oresentation of 
unobservable phenomena, ooerator training models, gaming 
models, design tools and models of systems with factors that 
preclude experimentation on the system itself [Rahe 1972], 

Modern computers and qraohics terminals have removed the 
last barriers that previously' dictated all-digital 
simulations. These terminals can be used as exceptionally 
fast and versatile output devices. The computer may be 
eouipoed with a grapnical input device such as a graphic 
tablet enabling the system to be used as a drafting aevice 
with unique prooert i es (Newman and Sproull 19731. 

The comouter system intended for use should provide on- 
line, hands-on high-speed computation with excellent 
displays and interfaces to external hardware. The 
application of graphical support to war gaming ados a 
dimension previously not available to the modeler. The 
capability to visually monitor the simulation during 
execution provides insight into the system being modeled 
that tabular results obtained after the fact can never hope 
to attain. Interactive programming allows the development 
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of applications which can interact with a user and enable 
him to control the functions oerformed and the data operated 
on by the program. The modeler may now interactively 
participate in the simulation and at critical times make 
decisions that will create changes in the outcome of the 
simulation. 

One important facet of interactive programming is the 
aspect of man-computer symbiosis. By achieving a very close 
coupling between the human and the computer, the computer may 
facilitate formulative thinking and allow the human member 
of the partnership to participate in making decisions and 
controlling complex situations without inflexible dependence 
on Dredetermined programs [Licklider I960]. 

Any system devised to attain such an interactive 
simulation system with graphical support should not be 
hastily thrown together. "Add-on 11 supoort tends to overly 
complicate and. reduce the efficiency of the existina system. 
For any system, the principles of simplicity and 
effectiveness are essential to the usefulness of the system. 
These two principles often compete with each other [Smith 
1970]. In this light, it is critical that to support any 
existing or planned system, a careful systems analysis and 
design must be the first step toward implementing that 
support. This added effort should result in an efficient, 
effective system while maintaining maximum flexibility and 
simplicity. In the rush to implement a major system, the 
emphasis is generally placed on the application with little 
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cons iderst ion given the human factors when the interface 
between man and his. proqram is implemented. Human interface 
is desirable at setup time when there are many displays, 
options and parameters for a user to control. If he is an 
experienced user he does not want to be forced to cycle 
through all the ootions. The user desires only enough 
promoting information to change those ootions necessary to 
setuo and execute his run# No matter how well a system 
performs* it will be little used if it is difficult to 
setup* The user must be considered first and effective 
man-machine interface dialoaue will oecome a major 
consideration, as important as the application itself. 

The process of extending an existinq war game to include 
interactive functions is so complex that programming 
productivity techniques must be planned and employed from 
the onset. These modern techniques have proven to be 
successful in control of software projects. Such techniques 
as structured design, top-down design, top-down programminq, 
modularization; structured programming and walkthroughs, 
chief programmer team concepts and a scheduling methodology 
will be crucial to the development and maintenance of an 
accept ab 1 e mode 1 . 

This study considers all possible software concepts and 
explores their applicability to the model. Some of these 
that could prove to be useful tools are: database management 
systems, SIMSCRIPT, graphic support languages and either 
general purpose or tailored versions of operating systems. 
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Various programming lanauages lend themselves to war 
gaming. The advantages of a high level language are well 
established and their usage is particularly significant in 
the area of programmer productivity. 8ecause each of these 
language instructions translates into 10-20 lines of 
documented code/ the daily productivity of the programmer is 
increased at least three fold. Jhis increase has been 
demonstrated in numerous studies [Brooks 19751. High level 
languages also contribute to lower application maintenance 
costs/ improved documentation and design through their 
ability to allow se 1 f -doc umen t i na variable names/ new 
constructs and easier i mo 1 emen t a t i on of alaorithms (stacK 
and queue manipulation for example). 

SIMSCRIPT is an example of a high level language 
especially developed for simulations. The internal functions 
of SUBSCRIPT such as the event scheduling/ queue 
manipulation .and system defined variables enhance the 
desirability for using it. FORTRAN subroutines can be 
readily called from the language allowing program efficiency 
to increase by employing critical code in the form of 
FORTRAN subroutines. The current version of SUBSCRIPT II. 5 
was written in SIMSCRIPT II. 5. This fact demonstrates the 
versatility of the language. In the last several years 
certain developments have improved the efficiency of 
SIMSCRIPT. Among these developments was the move from the 
generation of FORTRAN intermediate code to direct generation 
of machine code. Additionally/ the number of steps reouired 
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to compiler link-edit and execute a SIMSCRIPT proqram was 
reduced; shortening compilation time. 

This systems analysis parallels most systems analysis 
procedures but addresses the question; "What resources do I 
need to provide the desired capabilities given only the 
constraint of using SIMSCRIPT II. 5 as a base simulation 

language" versus "How can I design this system to run on a 

/ 

particular comouter". This is considered the appropriate 
approach to designing a system which truly meets the needs 
of the combat modeling community. Figure 1.1 deDicts the 
systems analysis procedures followed. 

UNCONSTRAINED SYSTEMS ANALYSIS STEPS 




FIGURE 1.1 



The first and key element of this systems analysis study 
was the identification of the user's objectives. Without 
this critical action the entire study would have been 
meaningless. The objectives fell into the three general 
areas of graphical display sudpo r t * simulation of the battle 
area and the capability to determine the status of the 

battle or any of the components- of the battle at any desired 

/ 

instant of time during the simulation. 

Once the user's objectives were determined* the next 
step was to select a set of general performance criteria. 
Performance criteria are the key to measuring the degree of 
success in attaining the objectives of the user. System 
performance measures must be considered to produce an 
efficient and effective system for the entire life-cycle. 
The system must possess the ability to reflect changes in 
both friendly and enemy force structures and tactics. The 
data reflected by the display devices must be current at the 
time of display. This could mean that the simulation would 
have to be halted until a signal is generated by the 
completion of the display. The duality of the data base 
will be reflected by the level of data integrity needed. Tne 
size of the data base must be such that only necessary data 
items be stored. Any abuse of this will surface in the 
response time for any display invoked and the overall amount 
of secondary storage reguired for the data base. The system 
was designed with growth in mind so that additional 
capabilities may be accommodated as new technology develops. 
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As tactics and force structures change* the system must be 
capable of easily absorbing these needed changes. Response 
time* another Derformance measure* is considered to be from 
the time a user depresses a carriage return after a display 
request until that request is satisfied. From other studies 
[Sutherland 1966] response times of greater than 10 seconds 

are not desirable since the human mind will become impatient 

/ 

after such a long waiting period. A good response time is 
usually three to five seconds. 

Alternative designs were conceived* each possessing the 
capability to provide all of the desirea functions 
identified as user objectives within the performance 
criteria established. Alternative conceptual designs are 
defined as concepts arrived at through "dreaming" with 
objectives and restrictions in mind. In order to attempt to 
capture the latest hardware and software capabilities and 
philosophys and incorporate them into this system* a certain 
amount of general research was conducted in the areas of 
simulation* interactive graphics* database design and 
implementation* operating systems and systems analysis and 
oes i gn . 

After the list of designs was consolidated into general 
concepts* each conceptual desian was evaluated to insure 
that the design under consideration met the objectives. The 
advantages and disadvantages of each alternative were 
determined. This reduced the list to only feasibile 
solutions to the problem. 
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Chanter II briefly discusses the history of war gaming, 
the evolution of . STAR, a current description of STAR and 
proposed enhancements with the support required to achieve 
them. This final version of STAR is the entire reason for 
this thesis, that is, the design of a system to reach this 
goal. 

Chapter III discusses the alternative approaches to the 
design of a support system for STAR. The alternatives 
include a database management system, an operating system, a 
distributed system and graphical routines imbedded in the 
simulation program. These alternatives are described and 
evaluated as to their individual capability to implement the 
system. A prefered solution was then chosen. 

Chapter IV continues with the analysis of the operating 
system needed to support the solution from chapter III. The 
basic features needed to support STAR are described and 
examples of their use are given. The modules of STAR not 
previously written are outlined to give guidance in future 
development activity. 

Chapter V presents the results of the analysis of the 
current version of STAR. This chanter summarizes tne 
findings of the analysis and presents modifications and 
recommendations that will lessen the storaqe reauirements 
for STAR while speeding up the execution of the model. 

Chanter VI contains conclusions from this thesis and 
recommends further courses of action to achieve the desired 
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II. BACKGROUND 



A. HISTORY OF WAR GAMES 

War games are nearly as old as organized warfare itself. 
Evidence has been uncovered that indicates the use of games 
to simulate war in ancient Egypt. Progress in war gaming is 
marked by a series of improvements in support techniques 
available to the user. 

During the latter half of the eighteenth century the 
Prussians developed an increased emphasis on warfare as a 
branch of applied mathematics. In 1780/ Helwig/ Master of 
the Pages for the Duke of Brunswick/ invented a game guite 
similar to the modern commercial war game. The game used a 
modified chessboard. Terrain was represented by using 
combinations of 1666 small squares tinted in various colors. 
These small squares were grouped onto the ooaro as terrain 
features. In 1795 Georg Vinturinus modified the game bv 
constructing a map board of an actual piece of terrain. 

In 1811 von ReisswitZ/ the Prussian War Counselor at 
Breslau/ transferred the war game to a sand table with 
terrain modeled in sand to a scale of 1:2373. In 1824 Army 
Lieutenant von ReisswitZ/ Jr. modified his father's game by 
transferring the game to a realistic mao-like chart with a 
scale of 1:8000. An umpire/ detailed rules/ and probability 
tables were also introduced by von ReisswitZ/ Jr. The size 
of the game was limited to approximately four square miles 
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of ground. The umoire not only monitored the play of the 
game for compliance with the rules but also imposed two 
minute time slices in the olayinq of the game. In this 
manner the game could be stooped, as desired, and a 
particular two minute round could be studied in detail. 

Further improvements occured during the ninteenth 
century. In 1866 Lieutenant Wm„ McC. Little suggested a 
game called "Naval War Game" that employed blackboards, 
sheets of paper or charts, or maps placed on tables to 
illustrate terrain. At about this same time celluloid sheets 
or overlays were introduced. Information drawn on these 
overlays was saved as a historical record that could be 
analyzed at a later date. This idea of overlays is 
attributed to the Naval War College. 

Early in the twentieth century, new maps prepared 
especially for map maneuvers showed large tracts of actual 
terrain. The oldest map of American terrain made expressly 
for mao maneuvers dates from 1906. This map of Fort 
Leavenworth, Kansas includes a tract approximately four 
miles in width by six miles in length with a scale of 1:5280 
and a contour interval of ten feet [JCS 1969] . 

In the post WW-II era, the military use of war games 
became increasingly sophisticated and widespread. 
Sophistication is achieved through increasing computer 
technology. The computer allows large amounts of data to be 
stored and manipulated without tedious bookkeeping on the 
part of the user. There is some debate over the usefulness 
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of such computer simulations. The amount of data generated 
is so great that it can overwhelm the user, thereby 
undermining the very reason for the simulation. 

Modern computer war games have seen evolution similar to 
manual games. One parallel development is in the terrain 
model associated with the game. Early games used flat 
(imaginary) terrain. Terrain advagced to idealized, easily 
constructed models that represented no identifiable terrain. 
The next step was to represent real terrain through the use 
of digitization at the expense of storage. The latest 
breakthrough is the use of oarametric terrain capable of 
modeling any real terrain in a size never before imagined 
[Needles 19761. 

B. EVOLUTION OF SIMULATION OF TACTICAL ALTERNATIVE RESPONSES 
(STAR) 

A significant effort is currently underway at the Naval 
Postgraduate School to develop a mid-resolution combined 
arms model to determine both hardware and training measures 
of effectiveness. One of the primary goals of the model is 
to achieve an acceptable level of resolution wnile assuri no 

t 

that the model incuts and interactions are understood bv the 
military decision-maker. 

Five theses completed over the last two years form a 
basis for continuing the model development. A oarametric 
terrain model was developed to provide a continuous macro- 
terrain represent at i on • This represent at i on has several 
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advantages over the classical approach of digitized terrain. 
L i ne-o f -s i gh t computations are made directly from 
mathematical relationships as opposed to the time-consuming 
iterative process required with digital terrain. Mobility 
is truly continuously as opposed to piecewise linear 
techniques used for digitized terrain. Terrain can be 
considered as a parameter of the combined arms analysis as 
opposed to a given. By appropriate selection of incut 
parameters/ any real section of terrain can be closely 
approximated by the parametric terrain model. Any size 
terrain sector can be easily generated without the storage 
constraints of digital terrain. A dynamic smoke module has 
been developed and operated in the parametric terrain model. 

After development of the terrain model# two theses were 
devoted to a target servicing evaluation of blue artillery 
against a red ground threat. The result of this effort was a 
working model programmed in SIMSCRIPT which provides dynamic 
representation of the artillery missions down to the 
individual element level. This model forms the basis for 
future enhancements of the combined arms model. An 
ammunition supply model was developed to represent the 
effects of such parameters as interdictive enemy fire# RAM- 
D# truck trips oer day to the ammunition supply point# truck 
replenishment rate# etc.# on the number of rounds available 
to the combat vehicles over any sustained combat period. 

Current efforts are underway to incorporate two-sided 
ground and artillery# with other systems as close air 
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support, minefields, cannon launched guided projectiles, 
advanced attack helicooters, air defense, etc. These 
enhancements will be made to the blue battalion versus red 
regiment model. In addition, a dynamic ammunition resupol y 
model is being developed. 



C. CURRENT DESCRIPTION OF STAR 

The structure of STAR is truly hierarchial in that it is 
not confined to any soecific unit size or con f i gu r a t i on . The 
parent-child set structure of SIMSCRIPT, coupled with the 
flexible parametric terrain model, provides the required 
capabilities to realize a hierarchial representation. The 
level of resolution is orescribed by the requi rements. 

The first study aoplication of STAR was in support of 
the 105/120mm ammunition stowed load requirements for the 
XM-1 tank. Initial oroduct ion runs for the study were 
conducted for a blue battalion versus a red regiment in 
December 1978. This version of STAR represented all 
aopropri ate ground direct fire units, two-sided artillery, 
minefields and smoke. Upon completion of the Phase I 
ba 1 1 a 1 i on- 1 eve 1 production runs (on a 10 x 10 km 
battlefield), Phase II was initiated. The result of Phase II 
was a b r i gade- 1 eve 1 model versus a red division on a 
battlefield approximately 50 x 50 km. The Phase II model 
will be capable of simulating a mu 1 t i -ec he 1 on red regimental 
attack on multiple avenues of approach in both the Covering 
Force Area (CFA) and the Main Battle Area (MBA). Extented 
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dynamic play of ammunition and POL resupply/ as well as a 
significant enhancement of the tactical rep r esen t a t i on of 
battalion engagements/ will result from the Phase II model. 
In addition/ artillery units will be directly represented on 
the battlefield/ allowing for soecific plav of 
counterbattery and counter air-defense fires. Finally/ a 
dynamic air-to-air defense model' is being developed for 
Phase II model representing two-sided air-to-air engaaements 
for both fixed and rotary wing aircraft. All appropriate red 
and blue air defense systems will be olayed in the model. 

The SIMSCRIPT language was selected for STAR because the 
language was designed for discrete event simulations. The 
many embedded features of the language give the programmer 
wide latitude in the construction of event flow. The 
language is English-like with regard to the construction of 
commands. The heart of the embedded .simulation facilities 
is the timer,; which is used with certain structural 
characteristics: entities/ attributes/ sets and events. 
These facilities greatly simDlify the process of writing a 
simulation program and debugging the code. This is further 
enhanced by a compiler which provides error messages and 
trace-back routines similar to WATFOR and rtATFIV in FORTRAN. 

The structure of STAR begins with the concept of an 
entity. An entity is s i mo 1 y a represent at i on or model of an 
item. In STAR the basic entity is a weapon system 
representing tanks/ TOwS/ artillery pieces/ etc. Any of 
these entities may be brought into ex i stance by a simple 
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phrase* which includes the name of the entity. For example* 
the phrase CREATE A' TANK reserves a place in memory for the 
entity and its attributes which the programmer has chosen to 
call TANK. Associated with the word TANK is a pointer 
variable which points to the location in memory where TANK 
is stored. It is desirable to associate certain 
characteristics with entities after they have been created. 
These c h a r ac t er i s t i c s are referred to as attributes ana are 
affixed to an entity by the internal bookkeeping procedures 
of SIMSCRIPT (the svstem) or are placed on the entity by the 
programmer. Attributes must be changed by the programmer as 
necessary to reflect chanqes in characteristics. Moreover* 
the system will change system-defined attributes as 
necessary. The concept of sets in SI M SCRIPT is very useful 
when it is necessary to group entities based on certain 
characteristics or in the construction of Queues. In STAR 
sets have been used primarily to oortray membership in 
organizations. The set structure mirrors organi zat ional 
structure and enhances the programmer's ability to model 
unit tactics from a micro to macro level. An entity may 
belong to any number of sets and the entity acaui res a 
membership attribute which facilitates identification of an 
entity's unit. 

An extremely flexible method of filing allows entities 
to be ordered in a set by ranking of certain attributes or 
by a simple f i rst -i n-f i rst -out basis. STAR uses the latter 
system for most applications. The set logic of SIMSCRIPT 
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allows this to be easily expanded to higher level 
organi zations. 

Each entity in STAR is modeled to reflect a flow of 
activities over time. In particular/ each entity initiates 
or undergoes search/ detection/ target selection/ firing or 
impact. These five events are scheduled dynamically based on 
the current tactical situation or'ap appropriate probability 
distribution. When an event is scheduled for an entity/ the 
SIMSCRIPT timer makes a record of the time that the event is 
to occur (in terms of overall simulation time) and the 
entity for which the event has been scheduled. Other 
characteristics of the event may be recorded in a manner 
similar to the assignment of attributes. At the appropriate 
simulation time/ the event is executed unless cancelled by 
some logic provided by the programmer. This event/ when 
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Event routines are supoorted by a number of 
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computational subroutines in STAR. Subroutines are written 
in both SIMSCRIPT and FORTRAN which has given the simulation 
a great deal of flexibility. The difficult 1 i ne-o f -s i gh t 
calculations* for example* are accomplished in FORTRAN 
because the terrain model was originally written in FORTRAN. 
It was this capability to call FORTRAN subroutines that made 
SIMSCRIPT an even more aopea 1 i ng' language . Existing FORTRAN 
routines could be used with only minor modifications. Other 
routines more closely tied to the entity structure of 
SIMSCRIPT were written in that language. The routine that 
updates the list of detected targets for each TANK is 
written in SIMSCRIPT to take aavantage of the dynamic 
dimensioning capabilities of the language and the pointer 
variable link listing techniques available. For large target 
arrays* these language features are extremely efficient in 
reducing memory regu i remen t s . 



D. PROPOSED ENHANCEMENTS 

The STAR combat model currently under development at the 
Naval Postgraduate School operates in batch mode on the IBM 
360-67 computer in the W.R. Church Computer Center. It is 
difficult to build a simulation model in a batch processing 
environment. Batch processing consumes much of the time in 
developing the simulation. Interactive simulation is more 
economical as well as more effective in problem analysis. 
One of the primary goals of this project is to expand the 
model to operate in an interactive mode with graphical 
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support. Figure 2.1 depicts the goals of 
modeler's ability to debug a simulation i 
by the interactive capabilities of a 1 
simulation user is constantly engaged 
simulation^ interactive capabilities 
feature of any support system [Mills and 
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The ability to actively particioate in this war game in 
an interactive mode would contribute to both the 
productivity and the flexibility of the model. In an 
interactive environments the player or modeler would be able 
to input decisions that would approximate those made by the 
commander on the battlefield. Through this man-computer 

symbiosis* the ability of the model to more accurately 

/ 

reflect the actual outcome of a battle would be attained. 
The actual flow of the battle could be altered to reflect 
realism rather than rigid programming which could lead to 
unforseen* unrealistic circumstances. 

A primary concern in the desian of an interactive 
simulation system should be ease of user particioation in 
the simulation during execution. To facilitate this ease of 
use* an appropriate interrupt facility is necessary to allow 
for suspension of the program at a given point in the 
program logic and for the transfer of control to the user. 
The interrupt handler should be flexible enough to process 
any appropriate reguest at any time and return control to 
the point of the interruption upon completion of the 
handling of the interrupt. This interrupt facility would not 
only allow input to the model and output from the model but 
also suspend the simulation to allow detailed examination* 
decision making and synchronization between simulation time 
and wall-clock time. 

The model should operate in real-time if Dossible. The 
term real-time* in the modeler's sense of the term* is not 
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entirely critical. In modeling terminology. real-time is in 
the sense of wall-clock time. One minute of clock time 
constitutes one minute of simulation. If simulation of a 
thirty-minute battle runs in thirty minutes of wall clock 
timer the simulation is said to run in real time. Real-time 
in the computer science vernacular is of utmost importance. 
A computer system is said to be running in real-time if 

y 

there is a computer Program and some other process runninq 
’’in-steo M in such a way that the associated process is not 
caused to run slower by the computer program. This could be 
exemplified by the simulation program and the graphics 
display process. If the simulation program sufficiently 
slows the interactive graphical input process that the 
inputs are received after they were needed for use in the 
simulation/ then the computer system is not running in 
real-time. The interactive caoability of tne model will oe 
useless if the incuts are not entered in sufficient time to 
effect the outcome of the battle. It is this real-time that 
the system must achieve. 

Facilities are needed to save the state of the model at 
any time by executing a single command. Conversely/ a 
command should be available to restore the simulation to a 
previously saved state and execution resumed from there. 
Such a caoability provides the ability to save intermediate 
states of the simulation run for the purpose of returninq to 
the previous points in simulation time. This technique is 
valuable in cases where an unexpected behavior enters the 
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simulation or an important behavior was bypassed before its 
presence was discovered tSohnle 1973J. 

Since the primary purpose of the game is to function as 
an analytic tool/ any support system must be capable of 
recording all interactive decisions for use in duplication 
of runs with alternate modelinq parameters. The flow of the 

oattle should also be recorded in ‘order to allow in depth 

✓ 

analysis at the conclusion of the simulation run if desired. 

There has been little imaginative use of computer 
graphics as an input/output tool for simulations. Some use 
of simple plotting has been used but the power of 
interactive graphics is relatively untouched. Interfaces to 
graohics languages will permit the modeler to provide more 
meaningful disolays for the simulation user. Input oy way 
of graphics has been grossly underestimated. Special 
purpose graphics input is a natural means of getting input 
with today's interactive graphics devices. 

The most fundamental capability of the proposed 
graphical support package is displaying maos of the 
battlefield. The standard mao is a 10 X 10km contour map. 
This map would be plotted by referencing one of 25 standard 
map sections. These 25 standard map sections would cover the 
50 X 50km battle area. By selecting one of the numbers from 
1-25/ the appropriate contour map would be drawn using the 
default contour interval of 100 meters. An alternate mode 
for plotting maos would De provided to allow the plotting of 
larger areas. Larger maps are reaui red to monitor such 
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missions as counter-battery fire or long range surveillance. 
These larger plots' would be called by referencing the lower 
left corner and the upper right corner utilizing four digit 
grid coordinates. Since the area to be Dlotted would be 
larger (or smaller if so desired) a contour interval must be 
supplied. Scaling will be oerformed as a function of 
maximum and minimum grid coordinates specified. 

The contour maps Drovided are the background for several 
types of overlays. These overlays may be selected singly or 
in any combination. The plotting of excessive numbers of 
overlays may lead to cluttering of the display screen and 
should be avoided. One such overlay is in supoort of the 
dynamic smoke module included in the simulation. The smoke 
overlay will show the location of smoke or other obscuring 
elements such as fog or rain. Density of the smoke is 
indicated by the intensity of the disdayed smoke. As the 
smoke dissipates the intensity decreases. The effect of wind 
on the smoke is shown by movement of the smoke display 
across the screen. Results of patrols and reconna i sance 
flights will be overlayed on the basic contour map. Targets 
detected by both ground and aerial observers are displayed 
while under observation. The results of active ground 
detection will be updated as reguired by movement of 
elements. The results of aerial r ec onna i sane e are static in 
nature after the completion of the flight. Other overlays 
include the display of road networks/ towns/ oostacles/ both 
natural and man made/ animation of firing events/ receipt of 
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enemy fire? nuclear planning aids and indirect fire. 

Dynamic route and position selection will be supported 
from the graphics terminal. By utilizing a light pen, data 
tablet? cursor? track ball? joy stick? thumb wheels or some 
other type input device? the player should be able to 
interactively input changes or supplimental information into 
the model during execution. The graphical support package 
also provides for the monitoring of unit movement through 
the use of periodic updating of the current unit position. 
During execution the modeler can select the level of the 
unit to be plotted. If the modeler selects a unit level 
other than individual element? the plotting of the unit is 
performed using the standard military symbol for the unit. 

Dynamic movement on the battlefield gives additional 
realism to the simulation and often discloses information 
that words cannot convey. Unit movement is represented as it 
occurs. The ..actual firing of weapons to include round 
flight and impact enhance the picture. Any compat introduced 
visual effects such as smoke from exploding rounds is 
depicted along with its dissioation and drift. One of the 
largest benefits of displaying unit movement is having a 
tool to debug the dynamic route selection module that will 
be developed for STAR. Unless the modeler has the capability 
to monitor the route taken by an element? he can never be 
certain of the performance of dynamic route selection or 
where that element is located. 

Another analytic tool to be furnished the modeler is the 
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ability to draw 1 i ne-o f -s i gh t (LOS) fans. These LOS fans are 
used to aid in selection of positions for weapons systems/ 
radars and other LOS dependent systems. Analytically/ these 
LOS fans serve to verify LOS calculations for firing events. 
The LOS fan will be represented by shading on the contour 
map/ the heavier the shading the greater the visability. A 
second type of LOS fan will be offered/ this being a 
compliment display that shades the area that cannot be seen. 

The support system will incoroorate an inguiry 
capability. Whenever a simulation creates significant 
output/ t fye statistics collection capabilities of the 
simulation language may not provide the modeler with the 
information needed. Statistics collection by a simulation 
language is often too general and if more detail is 
required/ a dump of the state changes of the model must be 
analyzed. This inguiry capability supports post execution 
analytic analysis by enabling specific information to be 
retrieved and thus avoid searching volumes of data to obtain 
a single data item. This feature of the war qame allows the 
various olayers from staff sections to inquire and receive 
information concerning any data the model maintains that is 
normally available to that staff member. For examol e the 
G-l/S-1 needs information concerning command strength/ 
losses/ individual and unit reolacementS/ friendly and enemy 
prisoners of war (POW)/ civilian personnel/ safety/ 
personnel services/ graves regi st rat i on / casulty reporting/ 
awards and decorations/ medical supply and maintenance/ 
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straggler disposition and headquarters movement* security* 
operation* rear command post location and visitors. The 
G-2/S-2 is concerned with recommending essential elements of 
information (EEI)* requests for target acgu i s i t i ons * 
surveillance* rec onna i sane e * i nterrogat i on of enemy POWs* 
debriefing* captured enemy documents* signal intelligence* 
intelligence interpretation, weather* predicting NBC 
fallout* situation maos* counterintelligence* recommendina 
proposed areas of operations to the G-3/S-3* intelligence 
training* aogressor forces if employed* civilian-military 
operations and camouflage. The G-3/S-3 is tasked with 
insuring the number and types of units assigned to support 
and accomplish the mission* attachment and detachment of 
units* organizing and eguiping units* training* preparing 
the operational estimate* integration of fire and maneuver* 
basic and special loads for weapon systems* oriorities for 
allocating critical resources* coordination and use of 
airspace* designation of bivouacinq areas* recommending 
general location of the command post* electronic warfare 
activities* communications and maintaining a current 
estimate of the situation. The G-fl/S-4 is concerned with 
matters of supply* monitoring the distribution of supplies* 
supervising the distribution of critical combat weapons and 
munitions* recommending prescribed loads* managing special 
weaoons* procurement and storage of special weapons* 
collection and disposal of excess equipment* maintenance* 
repair parts* evacuation or retrograde of unservicable 
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eauipment, transportation, refueling, construction, property 
control, food services, use of POWs and civilians and 
decontamination operations. This data is available in a 
tabular form similar to figure 2.2. 
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FIGURE 2.2 

The graphics oackage will include the capability to 
represent terrain in three-dimensional form. This facility 
enables the modeler to verify that the shape of the terrain 
used in the model is in reality a true reoresentat ion of the 
actual terrain. Three-dimensional terrain plotting also 
serves to verify LOS calculations and aids in selection of 
routes and positions. Through the use of three dimensional 
terrain, aircraft flight simulation is oossible. The viewina 
screen is capable of displaying terrain as seen from an 
aircraft. The display includes the terrain, vegetation and 
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all elements located on the terrain being traversed. 
Additionally this ' three-dimensioned terrain feature can be 
expanded to provide 360 degree scans from any point selected 
by the user. 

The use of color in graphical displays was determined to 
be of extreme importance. The representation of red and blue 
forces is an obvious advantage. The ability to use color to 
represent vegetation lends realism to the display. The 
number of items to be represented is so large that without 
color it will be difficult/ if not impossible/ to 
distinguish features displayed. 

A report writer is of practical importance to the 
analyst. This reoort writer will be highly formatted to 
provide statistics required by the analvst. The user will be 
able to SDecify the statistics to be displayed and the table 
will be generated automatically. Additional hard copy 
support will be available in the form of a copy device 
attached to the terminal that may be used to copy the 
current image on the display device. 

Any graphical supDort system devised would not be 
complete without providing assistance to the user ourina 
execution. Instructions for use must be available/ on call/ 
at any time/ with various levels of detail for various 
levels of experience in playing the game. This type of 
interactive counseling will be provided in the form of a 
helo function. - This help function will be provided for two 
levels of expertise/ the novice and the experienced. The 
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novice user needs information concerning functions 
available/ their formats and their commands. The expert/ on 
the other hand/ requires only a reference to the commands 
available since he is familiar with their formats. 

Certain tutorials and guides must be supplied to the 
user. Directions for position selection using the line of 

sight fans must be readily availabie for use during setup of 

/ 

the simulation. A military symbol library should be 
included with the descriptions of the available symbols and 
the method of placement of the symbol of the overlay. This 
description includes details of how the computer decides 
where the automat i ca 1 1 y generated symbol is placed. Any 
graphical support provided for this system must provide for 
an interactive means with which the user can generate the 
parametric terrain and verify it against the actual terrain 
or a map. This terrain oackage must provide not only 
assistance in design of the terrain, but also the capability 
to record the parameters selected for later use in the 
simulation. It is highly desirable that the user have the 
means to obtain a hard copy of this terrain generation for 
this verification process. 



E. TYPES OF GRAPHICAL DISPLAYS 

The graphical support oackage will consist of three 
separate types of apoli cations packages. The first type of 
support is provided in the form of monitors. These monitors 
are the devices that provide the selective terrain plots. 
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The terrain plots are selected by the user and displayed 
until the user elects to either terminate the display or 
request another sector. The display monitor reflects 
current unit movement located within the terrain sector. 
The user has limited control over functions of these 
monitors. These monitors have the basic function of 
displaying the contour maos. The user will be able to select 
from a standard set of 10 X 10km contour maps, or he mav 
specify a sector using grid coordinates and the desired 
contour interval. The user may also specify the unit or 
element to be displayed. These monitors have a selective 
zoom feature to allow the user to focus on a given area in 
greater detai 1 . 

A second type of display incorporates the inquiry mode 
of the support package. These displays will be alpha- 
numeric terminals. These terminals enable the various staff 
players to inquire about personnel f logistical and other 
routine affairs of a unit. Levels of inauiry are controlled 
by the user. The terminal initiates a hierarchical search 
with the highest level unit available* giving the option of 
makinq the inquiry at this level of resolution or displayina 
subordinate units at a level one unit lower. If the user 
elects to make his inquiry* then action is initiated to 
determine the type inquiry from a menu of possible choices. 
The information is then displayed and execution continues. 
Should the user elect to traverse through the hierarchy in a 
downward direction* the monitor will display the subordinate 
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units and ask the user to indicate the unit in which he is 
interested. This is continued until the user reaches the 
level he desires and the inquiry is initiated. 

A third type of display will provide the function of the 
master graphics console. This console is fully interactive 
and accomplishes all dynamic changes and selections in the 

program. This terminal is anticipated to be larger with 

/ 

greater resolution. The capability for drawing in three 
dimensions is realized at this terminal. All graphical 
requests are originated at this terminal with the possible 
exception of the inquiry functions. Inquiries may also be 
initiated at the a 1 oh a-nume r i c terminals. For ease in 
selection of the function to be performed) a menu selection 
technique is used. The user selects) by means of a light-oen 
or some curser positioning device) the desired function to 
be performed. This initial selection leads to the 
fulfillment of the user’s request or the display of another 
menu. In addition to providing the executive routine which 
manages the execution of the simulation, the monitor 
provides the ability for the user to interact with the 
simulation program directly from the terminal. This allows 
the user to not only observe, verify and record data, but 
also interruot the simulation to change parameter values or 
modify the model structure. Figure 2.3 depicts types of 
displays. 
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III. CONCEPTUAL SOLUTIONS 



The problem at hand is to imolement graohical suooort 
and inquiry capability to an existing war game without 
serious degradation of performance. This problem is 
generated by the merqing of several capabilities. These 
capabilities include maintainina a real time environment, 
sharing of common data items without data redundancy, 
process synchronization, accurate and timely displays and 
interactive participation by both the user and programs. 
The puzzle is to fit these areas into a complete picture. 
This puzzle is the very essence of this thesis. The basic 
problem has been simplified by one assumption. The type of 
computer utilized is i rrel event providing it is capable of 
performing to the specified standards. The question of 
mini, maxi or micro implementation revolves around the state 
of the art at implementation time and the purpose of the 
computing system itself. If this simulation system is to 
become highly portable, then the preferred choice may be a 
microcomputer due to its low cost and portability. If this 
simulation system is to run "stand-alone* 1 on a dedicated 
system, then it may be appropriate to develop the system on 
a minicomputer. If this simulation system is to share time 
with other programs in a mu 1 t i p rog r amm i nq environment, then 
the appropriate choice may be a large mainframe capable of 
both mu 1 t i p r oa r amm i ng and multiprocessing. This thesis 
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leaves machine choice to the individual implementer. 

Solutions to the puzzle fall into four general classes 
with various degrees of difficulty and performance 
standards. These choices include a database management 
system^ a tailored operating system, a distributed system 
and graphic subroutines embedded within the simulation 

itself. Brief descriptions of the characteristics of tnese 

/ 

four approaches are discussed in the next four sections. 
Section E evaluates each aporoach's ability to implement the 
simulation system. The preferred solution is chosen in 
Section F . 

A. DATABASE MANAGEMENT SYSTEM 

One approach to the oroblem of supolying graphical 
support to the STAR model is through the use of a database 
management system. A database management system is a 
collection of software procedures, designed to facilitate 
access to a data base. This data base is sharea by diverse 
users. In this approach the main simulation program, 
written in SIMSCRIPT, would act as a high-level language 
applications program. The user would interface with the 
applications program through the use of any standard 
alphanumeric terminal. The graphics routines would act as 
other high-level language applications programs. Since a 
database management system has the property of being able to 
present the same data to various users in differing formats, 
the applications programmers would have their own external 
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models of the data available to them [Curtice 19761 



This 



differing view would allow the graDhics programs to be 
written in some language other than SIMSCRIPT since at this 
time there is no provision for graphical support in 
S IMSCR IP T . 

The actual data that is being manipulated by the 
applications proqram is stored fn^a common area within the 
computer system. The function of the database management 
system is to allow the sharinq of the data and create data 
independence to allow for different views of the data. It 
is the responsibility of the database administrator to 
develop and maintain the schemas allowing this mappinq to 
occur [Martin 19761. 

Database management systems must interface with the 
operating system in order to accomplish the actual manning 
of data into memory. The operating system and the database 
management system must coexist/ but this does not 
necessarily limit the usage of a database management system. 
Operating systems are available under which any given 
database management system may operate. There is an 
important relationship that must be discussed. Database 
management systems and operating systems provide the user 
with a variety of common functions. The database management 
system design must take into account the services provided 
by the operating system in order to minimize costlv 
duplication. Some of the most common services provided by 
operating systems include process management/ file-system 
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support/ incut and output support and usage measurement 



(Wiederhold 1977].' Some operating systems also provide 
facilities for sharing of data segments [Organix 1972]. 

The use of a database management system has several 
advantages. The database management system supports multiple 
users of the system at any given time. Data redundancy is 
reduced if not eliminated. Applications programs are data 
independent. The database management system provides 
internal safeguards for data integrity [Date 19773. Post- 
execution analysis is also facilitated. The ability of a 
user to conduct inquiries is simplified by the adoption of a 
highly tailored data manipulation language. 

A database management system offers a broad range of 
facilities for organizing/ viewing and manipulatina 
information. The creation of data tables by the user 
reduires only a minimum knowledae of the system. Often new 
tables can be constructed automatically from existing tables 
on the basis of some format property of the original table 
IFram et.al. 1977], 

Typically/ data manipulation languages are written in 
English-like commands. With minimal training/ a novice user 
can do useful work on the database management system using 
the data manipulation languaqe. Many of the more common 
commands may be invoked in a dialog form in which the system 
prompts the user for additional data or instructions. 

One of the largest disadvantages is the addition of more 
overhead and hence additional execution time. Part of this 



probem may be overcome by the design of a compiled database 
management system 'instead of an interpreted one [Wiederhold 
1977], In a typical database management svstem, a single 
user command may result in the performance of several 
physical input or output operations. Each input or output 
operation must be initiated by the central processor unit. 
In a multiprocessing en v i ronmen t t ' this requires the seizing 
and releasing of the central processor unit several times to 
carry out a user command/ therefore a significant overhead 
due to task switching may be accrued. The order of 
increased complexity introduced to the system by the 
database management system concept must be considered. 
Database management systems are considered by many to be as 
complex as some operating systems and hence introduce an 
additional complexity factor over and beyond the operating 
system and the basic application programs. Figures 3. 1-3.2 
diagrams the roll of a Database Management System. 
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8. OPERATING SYSTEM 

Modern computer hardware is very powerful and may be 
used for a variety of tasks. The hardware machine is 
difficult and awkward to use. In order to simplify usaqe of 
the bare computer/ ooerating systems have been developed to 
provide a more hospitable interface with users. Operating 
systems have become so essential to efficient comouter 
operation that many peoole view them as inseparable from the 




hardware (Madnick and Donovan 197a] 



An operating system is a collection of software modules 
within the computer system that control the operation of the 
comouter. These modules simplify the use of the system, 
attempt to optimize performance and resolve conflicts within 
the system. The modules manage the processors, main 
storage, secondary storage, input/output devices and files. 
The operating system performs the task of scheduling the use 
of the computer. Sophisticated operating systems increase 
the efficiency and subsequent 1 y decrease the cost of using a 
comouter. 

Operating systems vary in comolexi ty from simole monitor 
systems on m i c roc omout e r s to sooh i s t i c a t ed large scale 
systems caoable of multiprogramming and multiprocessing 
while providing protection and interrupt hardware. 
Regardless of the complexity of the system, all operating 
systems provide binding for processors and memories. The 
operating system binds data to physical memory locations and 
output files to output devices. A process is Pound to a 
processor. The ability to perform binding is fundamental to 
all operating systems. 

Operating systems are somewhat distinct in their ability 
to provide protection mechanisms (Graham and Denning 19721. 
The first level of protection provided by operating systems 
is common to all reliable systems. This is the protection 
of the operating system itself from destruction by tampering 
due to the executing program. This tampering may be 
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accidental due to the miscalculation of a subscript or some 
similar mistake# or it may be an intentional effort to 
sabatoge the system. Whatever the source of the tampering# 
the operating system must protect itself. A significant 
difference in operating systems is the ability to protect 
classified data within the computer system. Some computer 
systems are secure only in the dedicated mode where only 
classified material is allowed in the computer and the 
security perimeter is external to the machine. A more 
complicated but more useful type of security is the 
multilevel mode. In the multilevel mode the system may have 
various users with varying levels of security 
classification# all competing for system resources 
simultaneously [Whitmore et.al. 1973]. The security 
perimeter is internal to the computer and provided by a 
mechanism of the operating system. Access permission is 
determined by the operating system. This security mechanism 

i 

may implement a desc ret i ona r y or nondescret ionary policv. 

Some operating systems are capable of mu 1 t i programm i ng . 
In a mu 1 t i p rogr amm i ng environment# several user programs are 
allowed to compete for system resources simultaneously 
[Dennis 1965]. It is the function of the operating system 
to decide which job will be run at any given time. It may 
be possible for the user to define the priority of the job 
to the operating system. If this is the case the operating 
system does not have the problem of enforcing a 
desc ret i ona ry priority policy. Determination of the 
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priority may be left to the operating system. Operating 
systems use various criteria for establishing priority. 
Methods include estimated length of execution, estimated 
storage requ i rement s , estimated execution time and estimated 
output lines. An operating system may also use a 
combination of these two technioues. It is left up to the 

operating system to limit the number of programs the system 

✓ 

will accept . 

Some ooerating systems allow multiprocessing (Smith 
1977]. In a multiprocessing environment the computer system 
has multiple processors, each capable of independent 
operation. It is the resoons i b i 1 i t y of the central 
processor unit (CPU) to coordinate or synchronize the 
functioning of the processors. In a system such as this it 
will be possible for one Processor to be performing 
calculations while another processor is controlling output 
to the line printer. 

The operating system not only provides memory management 
in the form of binding but also is caoable of creatinq 
virtual memory. Virtual memory allows the address space of 
the program being executed to be either greater than or less 
the the physical memory of the machine. Utilizing this 
virtual memory, the user need not be limited by the physical 
size of the main memory (Denning 19701. 

Another feature of operating systems is their ability to 
handle interrupts. Through the use of an interrupt handler, 
the operating system may accept an interrupt, process it 



«7 



according to the instructions in the interrupt handler and 
return execution to the program in orogress at the point of 
the interrupt. Operating systems have system defined 
interrupt handlers but many have provisions for the user to 
define his own interrupt handlers. 



C. DISTRIBUTED SYSTEM 

A distributed system is a computer system composed of 
multiple central processors that cooperate in problem 
solving. These CPU's may be spread ever many miles or 
located in the same room. In order for the distributed 
system to function# coordination between the processors is 
accomplished by a distributed operating system. 

The problem of extending the execution time of the model 
might be alleviated by the' concept of a distributed 
computing system composed of one computer to process the 
simulation portion and maintain a master data base and a 
smaller computer providing the graphics and inauiry 
capabilities. A distributed system has the chacteristic 
that the functions are distributed or spread over multiple 
CPU's each designated to handle a particular function. This 
approach becomes advantageous by usinq a second processor to 
reduce the work load of the main CPU. Consider the case of 
a front-end processor connected to a main processor as 
indicated by figure 3.3. 
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The front-end processor controls the interface with the 
user. Graphical displays and user command interpretation 
including editing are performed on the front-end processor. 
This allows the Dower of the main processor to be devoted to 
the computation bound simulation functions. In this case 
the main processor would have to pass the required display 
data to the graphics processor as needed. Assuming that 
this would take a small amount of time unaer CPU to CPU 
communication with a communication line of high transfer 
rate eaual to the slower rate of the two processors* the 
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main processor could continue to simulate while the graohics 
processor aenerate.s the display list and causes the display 
to occur. This would have the effect of halting the 
simulation for only a minimum time frame and thereby not 
significantly degrade the system. Should it be desirable to 
stop the simulation for some update of information from the 

graohics processor, an interrupt could be generated by the 

/ 

graohics processor and sent to the main processor which 
would then halt the simulation to receive the update. The 
problem of maintaining data integrity emerges from the 
aforementioned situation. There is no way to determine if 
the data to be changed exists at the time of uDdate or if 
the data displayed is current. This problem will have to be 
resolved by generating an update reguest, displaying the 
current status of the battle area and then updating the 
data. This must be handled through some automated means so 
that the user is not confronted with the problem, he has 
enough to be concerned with without the system complicating 
the situation for him. 

The distributed system functions as follows. First there 
must be established priorities that each CPU follows. For 
instance, on the simulation CPU, communication between CPU's 
has a higher priority than the simulation and can be 



represented by 


the 


f o 1 lowing 


pseudo 


code , "wh i 1 e 


( not 


commun i c at i ng ) 


do 


simulation" 


. This 


action will 


give 



priority to CPU-CPU communication, allowing the user's 
inguiries to be answered more raoigly. The graphics CPU 
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: 




continuously tests the terminals for the indicator that the 
user desires to perform some function. This can be also 
accomplished through an interrupt mechanism. Upon 
identification of the user's desired function* an argument 
list is constructed in conjunction with additional user 
supplied data* if required* and an interrupt is generated to 

the simulation CPU indicating that the graphics CPU desires 

/ 

to communicate. Upon receipt of the argument list the 

simulation CPU stops the simulation* stores the machine 

state and executes a "case" structure similiar to: 

switch(function-id)* 

{ 

caseCt): terrain information; 

case(i): inquiry* 

case(u): update* 



> 

passing back to the graphics CPU any resulting information. 
The graphics CPU now orocesses the information received from 
the host CPU and continues the function originally 
identified by the user* such as producing a display. 



0. EMBEDDED GRAPHICS 

The simplest and perhaps the most direct implementation 
of the desired capabilities is the execution of the qraphic 
capability from a direct subroutine call from the SUBSCRIPT 
simulation program. Figure 3. A depicts the embedded graphics 
approach . 



SI 



SUBROUTINE CALL 




FIGURE 3. a 



There are several advantages to this approach. The graphics 
package can be developed separately from the simulation 
model » keeping in mind that necessary parameters required by 
the display must be oassed from the simulation program to 
the graphics subroutine. A simple driver could minic the 
functions of the call to the graphics routine during the 
development of the graphics package. In the same w a y » 
should the graphics subroutine provide the interface with 
the user for the interactive oortions of the models certain 
parameters would have to be returned to the simulation 
program. These oarameters must define the type of function 
that the user desires to oerform along with any function 
parameters reaui red. The values of the parameters could be 
established through interoretation of light pen input from 
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the user. This interpretation could take the form of a CASE 
or nested IF type structure where parameter values would be 
established from an interpretation or series of 
interpretations of the light pen inDut. Once the parameter 
list is formed the graphics subroutine is called. 

There are disadvantages to this concept. Due to the 
nature of subroutine calls* the action of the simulation 
program is at a standstill until the execution of the call 
is completed. This will increase the execution time of the 
simulation program and thereby increase the wall-clock time 
reguired to simulate any given battle. This problem ceases 
to retain great importance if it is desirable that the 
simulation be halted to allow any update information to be 
passed to the simulation process and thus maintain data 
i ntegr i ty . 

Because data integrity is a requirement of the system* 
the graphical displays must be capable of depicting the 
exact state of the simulation uoon the display device. To 
change the route of march of a particular unit or element 
that item must be locateo in the depicted position at the 
time of the update or the exact position must be known to 
the user. 



E. EVALUATION OF ALTERNATIVES 
1. Common Considerations 



There 


are severa 1 


items 


that 


are common 


to all 


approaches . 


Included in 


these 


items 


are the use 


of color 
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displays# hard copy devices and the treatment of static data 
such as contour maps. Hard copy devices are required to 
record selective displays upon command of the user. Contour 
maps are thought of as any reaui red data to enable a rapid 
draw of the desired area of terrain. Once the parametric 
terrain data is constructed# prior to the simulation 

execution and during some system initialization Procedures# 

/ 

there is no need for the simulation process to have access 
to it since the simulation routines comoute any required 
terrain data dynamically during execution. There is only the 
need to have this data available to the graphics display 
routines. The impact of a hard copy device upon the 
solution is seen as device deoendent and therefore not of 
concern in the selection process. In the same manner the 
method of drawing contour maps is device dependent and the 
use of color is independent of implementation. These two 
factors are also omitted from the evaluation process. This 
evaluation focuses on the ability or inability of the 
alternative to support the simulation# evaluating failures 
on the lowest possible level. 

2. Database Management System 

In the dataoase management system aporoach# the 
simulation program assumes the role of a high-level lanquage 
applications program. All graDhica! routines except the 
inquiry program are also hiqh-level applications programs. 
The inquiry program is an applications program written in a 
tailored data manipulation language. 
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A database management system is designed to allow the 
sharing of data and. e 1 i m i na t e data duplication. Through the 
design of appropriate schemas/ the database designer is able 
to present each apolications programmer with an independent 
view of the data and allow the orogrammer to access any data 
within the data base. This aooroach presents a problem with 

multiple users attemoting to write data simultaneously. 

✓ 

This problem can be minimized throuah careful design and 
judiciously grant i nq write access to shared data. Should 
two users desire to write data to the same file/ the last 
copy written will prevail. 

The recording of dynamic events presents a 
significant problem to the dataoase management system 
approach. The ability of the system to accept and store 
input data from the user is routine to a database system. 
Anything that can oe input and stored may also be recorded 
on secondary storage media. The significant problem arises 
when the machine state must be saved. Only the operatina 
system has the capability to monitor and modify all the 
registers in the machine. For the database management 
system to save the machine state/ close cooperation with the 
operating system is required. When it is desired to return 
to a decision point to resume execution with another 
decision/ the database management system must relinauish 
control to the operating system while the ooerating system 
restores the values of the variables and the machine state. 

Flexibility of play will require the database 
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management system to maintain some mechanism to generate the 
appropriate data structure for the level of play. The 
flexibility of play is not an insurmountable oroblem but the 
mechanism to achieve this goal may be quite complicated. 
The flexibility of display will be quite easily attained 
since display is dependent only on the data stored once the 

data structure for storing the data has been created. The 

/ 

ability to store various force structures must also be 
attained by some dynamic means since the actual size of the 
data structure required will not be known until run time. 

The degree of interactive orogramming attained by the 
database management system will vary from routine to 
routine. The inquiry routines will have the full 
interactive characteri st ics of any database management 
system. The programs written in high-level languages are 
limited by the degree of interaction provided by the 
corresponding languages. The database management system has 
no means of incorporating interrupt driven processing. 
Interrupt driven processing requires action by the operating 
system and therefore a close relationship between the 
database management system and the operating system. 

The database management system approach will 
adversely affect the real-time capability of the program. 
Overhead in a database management system is extensive. The 
desirable trait of data independence requires the additional 
cost of address translation. Various references to the same 
data element require the system to translate these 
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references into the same ohysical memory location. 
Additional overhead in execution time is reaui red by the 
necessity to translate or compile input requests durinq 
execut i on . 

The report writer is facilitated by the database 
management system approach. The database design allows for 

the user to request information in a standard format and 

/ 

have it displayed for him on the screen. Any information 
stored may be displayed as well as any combination of data 
items that may be created using relational calculus or 
standard boolean operators. 

3. Operatinq System 

Under the operating system concept* the simulation 
program becomes one of many in a mul tiorogrammina 
environment. The graphics routines are organized into 
programs with related functions. These graphics proqrams 
become additional programs that will compete with all other 
programs for system resources. 

The problem of sharing files is not significant to an 
operating system that uses segmentation. Any progran 
division that is important enough to be named may be created 
as a segment. In a system supoort ing this segmentation* any 
segment may be addressed by potentially any processor. By 
careful desianation of the ability to read and write to a 
given segment* it is possible to allow a segment that is 
responsible for a file to create the file and to allow a 
segment that must use that data for display or other 
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puPDoses Co access the data and use it. These segments that 
are sharing the data need not De in the same program. The 
programs need only be active at the time of sharing of the 
data. One potential problem may arise if more than one 
segment is allowed to write to any one data segment. In 
this case the last segment to write will be the segment that 

dictates the data value written.- By carefull design of the 

/ 

programs involved/ this problem may be made insignificant. 

The ability to record dynamic events such as 

decisions by the user and simulation status present no 
significant problem for the ooerating system. At the time 
the user inputs his decision/ the operating system needs to 
write the input data into the aDorooriate area in memory to 
affect the simulation. At this same time the operating 
system will make a copy of the decision information along 
with the machine state and any pertinate variable values 
before the decision is made. This additional information 
may be written to some secondary storage medium for use at a 
later time. At a later time when it is desired to return to 
a given decision point and change or modify the previous 
decision/ the operating system has all the information 
needed to restore variable values and restore the machine 
state. Execution may then resume from the Point of decision 
rather than regui ring the entire simulation to be executed 
aga i n . 

In the area of flexibility/ the operatina system 
approach presents no problem. It is the normal function of 
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some operating systems to allocate storage for proolem 
elements. At execution time the oDerating system will 
allocate storage as required by the simulation program. 

The area of interactive orogramming is affected by 
the interactive capabilities of the programming language. 



These built 


in capabilities 


are the 


base 


level 


for 


the 


simulation. 


Further interactive 

✓ 


capabilities 


may 


be 


provided by 


the operating 


system. 


For a 


system 


t o 


be 



genuinely interactive* it is necessary for the system to be 
interrupt driven. In an interrupt driven system* the user 
generates an interruot and the operating system then 
transfers control to the appropriate interrupt handler. The 
instructions in this interrupt handler dictate the response 
to the interrupt. Operating systems allow the user to write 
his own interrupt handlers to either supplement or replace 
the system provided handlers. In the event the user elects 
not to provide his own handler* the operating system 
provides default handlers. By anticipating the required 
types of interrupts and the appropriate responses* the user 
may effectively interruot the execution* create a display or 
input data* and return to the point of interruption and 
continue execution. 

The operating system approach may enhance the real 
time capability of the simulation. A multiprocessina 
environment allows the operating system to perform 
computation on one process while simultaneously performing 
input/output* paging or some other operation on another 
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process. This means the programs of the simulation may 
fully utilize the processors of the computer system and the 
processors need not be idle while a single proaram switches 
from one processor to another leaving the rest of the 
processors idle until the simulation needs its services. As 
a worst case? the ooerating system will add no more 

execution time to the proaram. The operating system is 

/ 

needed to provide user interface to the bare machine and 
hence is already present as overhead to any program run on 
the machine. 

The cost analysis report writer is still another 
program to exist in the mu 1 t i or ogramm i ng environment. The 
operating system keeps the segments belonging to all 
simulation Drograms on call until the report writer 
completes its usage of the data. Once the report writer 
concludes execution, the system is allowed to free storage 
for other usaae . 

A. Distributed System 

The envisioned solution would have two central processors. 
The simulation functions will reside on the main processor 
due to it's computation bound characteristics/ while the 
graphics and inauiry functions will reside under the control 
of another possibly smaller processor. 

Since the main CPU is charged with the responsibility 
of maintaining the master data base, there can be no sharing 
of data items between processors. The qraphics processor 
must receive all data items that are dynamically changing. 
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It must also interpret all user commands and aenerate a CPU 
to CPU request fo.r the data items necessary to fulfill the 
user's request. Any attempt to store these ever changing 
items is fruitless and will result in either duplicated 
files or excessive data transmission between the two CPUs. 
The request for data must be be generated on an interrupt 

basis to the main processor so .that the* excessive data 

/ 

transmission and data redundancy situations do not occur. 

Dynamic event recording must be accomplished on Doth 
processors to enable system to be restarted at any specified 
state. The graohics processor will be required to store 
user commands and decisions? machine state and perhaps 
disolay generation data. The main CPU will be tasked with 
saving its machine state and all variable values for the 
simulation restart. 

Flexibility of the system now soreads over the two 
processors. Not only must the imolementer be concerned with 
the mechanism for level of play? level of display and size 
of forces represented but also the corresoondi no volume of 
data transmission between the two processors. This is an 
added concern in the distributed aporoach. 

Since interactive play is desired? the graohics 
processor must interpret the user's commands in an 
interactive role and also generate an appropriate interruDt 
to the main processor for each type of request. This will 
require a user written interrupt handler on tne main 
processor to decipher the interrupt and process it. The 
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interrupt handler will orobably not be on the operating 
system level and thereby will cause additional delay Drior 
to process i ng it. 

The idea of distributing the STAR system functions to 
two processors was conceived to solve the real-time 
requirement problem. Certainly the distributed system would 
run closer to real-time than a subroutine call system. The 
required CPU to CPU communication will generate some 
overhead that other approaches do not. The user must see the 
current situation status displays and his participation must 
be received in time to accurately effect the outcome of the 
battle. 

The problem of where to locate the report writer for 
post -execut i on evaluation arises. It should be capaole of 
providing the user with his reauirements at the location 
generating the displays. This means that the main processor 
must either continue to function only to Pass data to the 
graphics processor for this purpose or create a file that is 
readable by the graphics processor during this phase. Once 
again additional overhead is required to accomplish both. In 
the first case additional execution time is required by the 
main to retrieve, process and transmit data to the graphics 
processor. In the latter case additional time is required 
to create the readable file should the two processors expect 
different file c h a r ac t e r i s t i c s . The overhead of generating 
the file remains in either case and under all concepts 
discussed, however such record and file attributes as 
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header, trailer, inter-record gaps, blocki.no characteristics 
and character set - will oresent a problem should two 
different hardware vendors be chosen for the two processors. 

Since unchanging data items, such as terrain and road 
networks, exist during the execution of any aiven 
simulation, they are stored on the graphics side of the 
system originally and do not require the passing of large 
data structures as that of terrain represent at i on . This is 
possible due to the use of parameterized terrain generation 
capability of the simulation to produce terrain elevations 
at any given point on the battle field. 

5. Embedded Graphics 

In this approach the simulation program is the center 
of control over all desired functions. The basic functions 
of graphical display, inquiry and update are fullfiled 
through calls to aporopri ate subroutines. 

SIMSCRIPT uses a basic technique of executing subroutine 
calls from the timing-routine. This technique selects the 
next event to transpire from the event list. These events 
were previously scheduled by other subroutines in the 
simulation (internal) or received as input (external). 

The sharing of information between the three basic 
functions (simulation, graphics and inquiry) presents no 
problem because the required common data can be stored in 
global variables or passed as arguments between the callinq 
and called subprograms. Data integrity also presents no 
particular problem since only one subprogram may be in 
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execution at any one time unless some type of parallel 
processor is utilized* The same argument applies when one 
subprogram updates a variable value that another uses. 

The recording of dynamic events can be easily 
accomplished except for retention of the machine state. 
Since machine state is important from the standpoint of 

restarting the process from a specified state/ an assembler 

✓ 

level subprogram is reauired to periodically save the 
necessary information on some secondary storage medium. 
Routines will also have to be developed to retain the 
decisions reached and periodic simulation state/ however 
these can be written in the basic simulation language since 
all required information is defined to the simulation 
program * 



F 1 ex i b i 1 
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level 
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initialization of key execution parameters. The structure 
to allow this must be incorporated into the subprograms so 
that the maximum allowable force sizes can be allowea. 

Interactive play can be achieved through careful design 
and implementation. A suborogram to periodically test 
disolay terminals for user Darticioation is required. This 
suborogram will interpret the user's desired functions and 
schedule the compatable event which is stored in the 
timing-routine event list in time sequence. These events 
may be scheduled NOW/ IN 10 MINUTES/ or AT ia30 HOURS/ 
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however/ 



NOW does not imply instantaneous execution of the 



function since other previously scheduled events for the 
same time could exist with a higher statically defined 
p r i o r i t y . 

Maintaining a real-time environment is not hindered by 
this approach when considering effect on the outcome of the 
simulation/ however this aporoach w^i 1 1 extend the execution 
time required for the battle. Should the user desire to 
update the simulation data during the execution/ the 
simulation process is halted by the resident operating 
system until control is returned. The user need only 
schedule a display and an update NOW or at the same time 
with the display event having the next hiahest prioritv to 
the update event. During execution the display will be 
produced/ showing the current simulation status and then the 
update event will execute. 

The report^wri ter enhancement presents some difficulties 
particularly during pos t -s i mu 1 at i on evaluation. Since the 
execution of the simulation has been terminated/ a seoarate 
application orogram is required to process the saved data 
for the user. 

Although the subroutine call aporoach is the simplest to 
implement/ it does have the drawbacks indicated. This 
approach will have several beneficial s i de -e f f ec t s . The 
graphic disolay is scheduled along with all other events and 
is placed in the event list in the appropriate time 
sequence. A display event can be generated with the SCHEDULE 
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A GRAPHICS. DISPLAY NOW, SCHEDULE A GRAPHICS .DISPLAY IN 10 
MINUTES (DAYS or UNITS) or SCHEDULE A GR APH I CS . D I SPL A Y AT 
1400 HOURS. This side-effect qives built-in flexibility to 
the scheduling of a disolay. The " GR APH I CS . D I SPL A Y " event 
includes initiation of inquiries and updates to the data 
base as well. Figure 3.5 depicts sample SIMSCRIPT code for 
this type of subroutine call. 
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preamble 



NOTICES INCLUDE S TOP . S IM1JL A T I ON 
EVERY LOC. UPDATE HAS A VEHICLE 
EVERY LOS. UPDATE HAS A WHEEL 






EVERY DETECT HAS A WHOLE. TANK 

DETECT. FOE. ENT I RE. TANK 

EVERY TARGET. SELECT HAS A FIRING. TANK 


AND 


A 


EVERY FIRE HAS A SHOOT I NG . T ANK 

CORE. POINTER. OR. TGT. ID 


AND 


A 


EVERY IMPACT HAS A TANK . THAT .SHOT 

BLOCK. POINTER. OR. TGT. ID ' „ 


AND 


A 


EVERY GRAPHICS. DISPLAY HAS A COMMAND 

ADDRESS .OF. PARAMETER. LI ST 


. ID 


AND 



END 



MAIN 



CREATE A 
LET 
LET 



• 

SCHEDULE 
LET 

PARAMETER. LIST 

END 



EVENT GRAPHICS. DISPLAY 



IF COMMAND. ID(GRAPHICS. DISPLAY) = ’I* 

PERFORM INQUIRY 

ADDRESS. OF. PARAMETER. LIST (GRAPHICS. DISPLAY) 
IF COMMAND. ID(GRAPHICS. DISPLAY) = ’DT' 

PERFORM TERRAIN. PLOT 

ADDRESS .OF. PARAMETER .LIST (GRAPH ICS.DISPLAY) 



END 



GIVEN 

GIVEN 



PARAMETER. LIST 

ATTRIBUTE! (PARAMETER. LIST) = valuel 
ATTRIBUTE2(PARAMETER.LIST) = value? 



A GRAPHICS. DISPLAY NOW 

ADDRESS. OF. PARAMETER. LI ST (GRAPHICS .DISPLAY) 



FIGURE 3.5 
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F. PREFERRED SOLUTION 



In the selection of the preferred alternative* those 
items designated as common considerations play an 
insignificant role. The use of color to enhance the clarity 
of the displays is not envisioned to introduce an additional 
burden on any solution. The method used to rapidly produce 

a contour map is device dependent and not dependent on the 

✓ 

preferred solution. Hard copy devices depend on machine 
interfaces and are therefore implementation independent. 

It is possible for all alternative solutions to 
accomplish the sharina of date files. Database management 
systems are designed with this goal. Database management 
systems produce a data independence that allows each user to 
view the data in his own way. Operating systems that 
support segmentation are also capable of supoortina the 
sharing of data. The operating system however shares the 
data in a format specific manner. The distributed approach 
allows sharing of data files between the central processors 
through the use of a distributed operating system that 
allows CPU to CPU communication. The subroutine call 
approach uses common data elements through parameter passing 
technigues and global variables. 

Dynamic event recording is the first area in which 
the four approaches differ significantly in their ability to 
Perform. All approaches are capable of recording decisions 
and saving the values of variables at the time of the 
decision. It is not a normal database management function 
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to record and later restore the state of the machine 



registers. This interface with the machine must be made 
with the cooperation of the operating system. The operatina 
system aporoachf on the other handr has the interface with 
the machine registers as part of its normal operations. The 
distributed aoproach is further complicated by the need to 

save the state of multiple CPU's and variable values in 

/ 

multiple machine memories. The subroutine call approach 
suffers from the inability to directly access machine 
registers in much the same manner as the database management 
system. 

Flexibility in the level of display and the level of 
play must be discussed in two aspects. Level of display is 
a function of the level of play in the fact that the only 
possible items to be displayed are those items that are 
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store the appropriate data structure. This ooses a problem 
to the database management system approach in that the 
system must dynamically generate the data structure at 
execution time. The generation of the maximum size data 
structure at every execution of the simulation would be 
wasteful of storage. The operating system approach is not 
hindered by the flexibility constraint. The operating 
system will automatically reserve storaoe for the data 
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structure specified bv the simulation program. The 
distributed approach is similar to the operating system 
approach in that the operating system of the distributed 
system will allocate storage as reguired by the 
corresponding programs. The subroutine call approach is 
unaffected by the flexibility of play. By changina input 
parameters^ the user may dictate the size and structure of 
the units participating in the simulation. 

Interactive programming for the database management 
alternative is broken into two areas. The inquiry mode of 
the database system is limited only by the database 
designer. When the user asks and what he is allowed to ask 
are design considerations. All interactive capabilities 
other than the inquiries are limited by the programming 
language concerned. The subroutine call approach is also 
limited by programming languages. The operating system 
approach is capable of fully interrupt driven processing. 
The ability to interact is enhanced by the users ability to 
write interrupt handlers to respond to user generated 
interrupts. The distributed system's user programs are also 
limited by the chosen programming lanquage. 

Real-time processing is hindered by the database 
management alternative. The system must translate all data 
references into the appropriate addresses in order to 
complete the data references. The operating system approach 
does not affect the real-time ability of the simulation. 
The distributed system will slow the simulation due to the 
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time required for CPU to CPU communication. The greatest 
slow down will be for the subroutine call alternative since 
all processing must stop in the simulation while the 
subroutine creates the display data. 

From the above discussion the operating system 
aoproach is the only alternative that satisfies all the 

requirements for the system. -There are several other 

/ 

considerations that favor the operating system approach. In 
the operating system approach the kev is the sharing of 
data. The key data to be shared is generated by the 
existing simulation proqram. Further oroqram development to 
share this existing data may be done independently without 
adversely affecting the existing program. 

Another consideration is the availability of a system 
to support the simulation. Both the database management 
system and the operating system approaches depend upon a 
complicated programming effort. A tailored database 
management system would have to be written and at best be an 
experimental system with unknown efficiency. On the other 
hand, general purpose operating systems capable of 
supporting this simulation system have been written and 
tested. These proven systems are available today. 

It is anticipated that the simulation wil be run with 
classified inout data. All solutions to the problem, except 
the operating system approach, delegate the problem of 
security to an external mechanism. Some operating systems 
are capable of providing security for the classified data 
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without depending on an external mechanism. 

The last consi derat i on is the complexity of the 
solution. The operating system approach places the entire 
burden on the operating system to perform tasks beyond the 
capability of the programming languaae. The database 
management system requires a complicated relationship 
between the database system and' the ooerating system since 
the database management system is unable to fulfill all the 
requirements. The operating system is the only alternative 
to perform all reauirements in a stand-alone basis. 
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•IV. SOLUTION ANALYSIS 



System analysis examines the existing and proposed 
software and produces the logical design for the system. It 
is in this chase that the inter-relationships between 
modules are examined , including determination of both 
coordination and synchronization of modules. The proposed 
simulation system is conoosed of four programs existing in a 
mutually cooperating environment. The first and most 
important of these four proarams is the monitor program 
which is the master program that coordinates the use of the 
system and is capable of initiating anv of the capabilities 
of the system. A second program is the simulation program 
itself. This program is the current version of STAR. The 
third program is a graphics program that produces all maps 
and overlays to the maps. The last program contains all 
administrative routines such as report writers/ inguiry 
operations/ all tutorials and assistance functions. The 
operating system coordinates these programs and converts 
isolated programs into the simulation system described in 
Chapter II. 

A. OPERATING SYSTEM REQUIREMENTS 

In order for an operating system to properly implement 
the simulation system/ it must have a number of control 
features. These reaui red features fall into the four 
functional areas of segmented memory/ multiprocessing/ 
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synch ron i zat i on of orocesses and segment isolation. 

1. Segmented Memory 

The sharing of data between user programs is requi red 
to implement the STAR model. The simulation generates a 
data file that is displayed by the various graohics 
routines. This data file is accessed by the routines that 
display dynamic movement , animate ^weaoon firing, display 
impact of rounds, and display unit positions as well as 
detected enemy positions. This data must not only be 
accessed but also be updated by the routines that enable 
dynamic route and position selection and support the inguiry 
functions. An operating system capable of segmented memory 
allows this sharing to take place [Daley and Dennis i960]. 

A segment is a collection of information that is 
important enouah to be given a name. A segment is the basic 
unit of sharing. Associated with a Segment is a collection 
of attributes* including a unigue identifier and an Access 
Control List. The Access Control List maintains information 
specifying the processes that may access that segment and 
whether the authorized access includes any combination of 
read, write or execute permission. Each segment may 
consists of up to six major parts. The text section 
contains the pure unmodified parts of the object code which 
would contain the program constants as SDecified in the 
SIMSCRIPT PREAMBLE. The definition section contains 
nonexecutable information used by system orogrammers in 
debugging and by the ooerating system in dynamic linking. 
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The linkaae section contains the impure/ modifiable parts of 
the object code and may be made up of two types of data. 
The links used to establish addresses at run time are the 
first tyoe of entry and since the memory is demand paged/ 
these addresses may change. The second type of data is the 
data items from the program that will be modified during 

execution. All variables will be stored here. The static 

/ 

section may also be used for storaae on a oer process basis 
alternately this storage may be included in the linkage 
section. A break map section contains information used by 
debuggers. The last section/ the symbol section/ contains 
anything generated that is not stored elsewhere [Honeywell 
19751 . 

All segments that are competing for system resources 
are listed in a system-wide Active Segment Table. This 
table allows the ooeratinq system to know which segments are 
currently active and where they are located in memory. 
Table length is finite which requires the operating system 
to limit the number of segments capable of competing for 
system resources. This limiting of processes reduces the 
amount of time lost due to the switching of processors from 
one process to another. 

2 . Process States 

A Drocess is a set of related procedures and data 
undergoing execution and manipulation. Processes will 
generally contain one or more Drocedure segments/ one or 
more data segments/ a stack segment and a linkage segment 
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for each procedure segment included in the process. 
Processes within a' computer fall into one of three execution 
states. A process is said to be running if it is currently 
executing on a processor. A process is ready if it would be 
running should a processor be available. A process is 
waiting if it cannot make immediate use of a processor since 
it is waiting for some external (to the process) event. The 
operating system keeps track of these processes in the 
system-wide Active Process Table. These three types of 
processes in the Active Process Table require synchronized 
use of shared segments. 

3. Synchronization of Processes 

In order to synchronize processes some method of 
communication between the processes must exist. This 
interprocess communication is monitored by a mechanism known 
as the traffic controller which functions as a general 
purpose supervisor for control of parallel operations (Daley 
ana Dennis 19681. Two of the more interesting mechanisms 
provided by the traffic controller are the block and wakeup 
functions. The block function forces a orocess to wait for 
an occurrance of an event generated by some other process 
while the wakeup function allows the process to be notified 
that the event has occurred and processing may resume. This 
blocking of a orocess is recorded in the Active Process 
Table. 

Another mechanism used in synchronization is a 
condition handler. Users and Drocesses may communicate with 
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processes through the use of condition handlers. Condition 
handling refers to an activity resulting from a hardware or 
software condition named by the user's proaram. The user 
may implicitly or explicitly identify the code to be 
executed in response to the condition. To initiate user 
interaction with the simulation* the programmer specifies 
the pressing of the ATTN key on the terminal keyboard as a 
hardware condition. In response to this condition* 
execution control is transferred to a condition handler 
which contains code to request the type of action required 
by the user. The user oerforms his desired interaction and 
the simulation resumes execution. Condition handling need 
not be a rigid response to the specified condition. The 
programmer has the option to specify condition handlers on a 
segment by segment basis since condition handlers are pushed 
onto a stack as they are defined and popped from the stack 
when the procedure segment for which they are defined is 
exited. In this manner* the programmer may specify a global 
condition handler as the qeneral response to a given 
condition and redefine the response to the condition on a 
procedure by procedure basis should the response chanqe for 
each particular environment. Should the response to the 
condition be the activation of another procedure* the 
condition handler then becomes another of the deliberately 
cooperating procedures. 

Deliberately cooperating programs or procedures may 
interact through the use of interrupts which are synchronous 
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events internal to the machine. When one procedure desires 
to call another procedure# the calling proceoure generates 
an interrupt. The key to flexibility in interrupt handling 
is to convert this interrupt to a wakeup . The interrupt is 
sent to the interprocess communication controller which in 
turn sends a wakeuo to the called procedure. This called 

procedure is then activated and execution may resume. There 

/ 

is no problem with simultaneous use of a procedure by 
multiple calling procedures since all references to the 
called procedure are made via the calling procedure's 
linkage segment. Once the called proceoure has completed 
execution# the called procedure places itself in a blocked 
status to await further use [Graham and Denning 19721. 

Coordinated sharing of writable data segments may be 
handled through a lock mechanism provided by the operating 
system. This lock mechanism is applied to a data segment 
whenever that segment is being utilized by a process capable 
of modifying its contents. Further attempts to reference a 
locked segment will be denied until the segment is unlocked. 
The lock mechanism blocks the process that is attempting to 
use data segment and maintains the identification of the 
requesting process in a list structure. Once the segment 
has been updated# the locking mechanism sends a wakeup to 
the next process selected to use the data# unlocking the 
data segment for that process. This procedure is repeated 
until all requests are fulfilled and the data seament is 
unlocked to await future use. 
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4. Isolation Techniques 



Interprocess isolation is accomplished through the 
Access Control List discussed in section A-l of this 
Chapter. Intraprocess isolation is implemented through the 
use of concentric protection rings where a ring bracket is 
associated with each segment. The ring bracket is an 
ordered triple <R1/R2/R3> which specifies the access bracket 
<R1/R2> and the call bracket <R2/R3>. These two subsets of 
the ring bracket dictate the read/ write/ execute and call 
access for that segment. A procedure may execute in any 
ring from R1 to R2 inclusive and may be called by any 
procedure in rings (R2 + 1) to R3 inclusive/ provided the 
calling procedure has sufficient security clearance. A data 
segment commonly has R2 eaual to R3 since calling a data 
segment has no meaning. A procedure segment may write to a 
data seament in rings 0 to R1 inclusive and read from a data 
segment residing in the region 0 to R2 inclusive. Again/ 
read and write access are denied to any segment in any rinq 
that does not have sufficient access qranted in the Access 
Cont rol List. 

A segment may also have a security level associated 
with it. This security level is composed of two parts/ 
security classification and security cateqory [Schiller 
1975). The security classification is a type of 
compa r t men t a 1 i z a t i on similar to the Department of Defense 
security classifications secret/ confidential/ etc. This 
security classification is a totally ordered set where 



79 



secret is strictly greater than confidential and so forth. 
The second part of the security level is the security 
category whicn is a modifier to the security classification 
and analoqis to the Department of Defense categories of 
crypto* NATO* etc. In addition to access granted by the 
Access Control List* procedures must also have an 
appropriate security level in order, to gain access. 



B. ANALYSIS OF ENHANCEMENTS. 

Certain design characteristics must be followed in the 
design of all software for the proposed system. All 
software developed should be easily portable* avoiding 
locally produced library functions since they may not exist 
at another installation. All modules should be human 

engineered to permit easy use. Operator inputs should be 
minimal and concise with default values provided for all 
modes* parameters and variables. These defaults lessen the 
burden on the user and facilitate the requirement for 
minimal input. Additionally* defaults reduce the number of 
user errors. Maintenance responsibility for the software 
must be charged to a specified individual or group of 
knowledgeable individuals. All graphics routines developed 
should comply with the new graphics standards under 
development by the American National Standards Institute 
[Newman and van Dam 19783 . 

In addition to the existing simulation program* several 
new modules and separate programs must be written to achieve 
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the type of interactive simulation described in Chapter II. 
These additional modules and programs include all graphical 
displays? inguiry, synchronization and report generator 
f unc t i ons . 

The choice of utilizing the operating system approach to 
implement the simulation system has facilitated the 
programming effort reaui red. The' area of flexibility of 
play no longer concerns the programmer. Storage for 
variables is automatically allocated as a normal function of 
the operating system. The programmer does not need to 
concern himself with an elaborate data structure that is 
capable of growth since this burden is assumed by the 
operating system. Flexibility of display becomes a problem 
of searching for all the elements of the unit being 
displayed and then using some appropriate weighting factor 
to properly position the unit symbol. 

Programs may be developed independently of the 
simulation by using simulated data files and therefore not 
hinder the use of the simulation or require duplicate copies 
of the simulation program for developmental purposes. When 
the additional programs are tested and Pronounced ready for 
use» the only action reaui red is to inform the operating 
system to allow access to the shared data files. 
Synch ron i zat i on of use of these shared files is reguired but 
mechanisms discussed in section A-3 of this chapter allow 
this sync h ron i za t i on to occur. 

1. Interactive Programming 
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The area of interactive programming may be broken 
into two sections. The user may interact with the simulation 
program as well as the individual simulation proqrams 
interacting with each other. The case of the user 
interacting with the simulation may be satisfied by the use 
of condition handlers while individual programs cooperating 
with one another may be accomplished through the use of 
interrupt handlers. 

An example of condition handling may be the 
implementation of dynamic route selection. When the light 
pen is activated* a hardware condition occurs and execution 
control is transferred to the condition handler. The 
condition handler sends a wakeuo to an updating procedure. 
This uodating procedure accesses the data and places a lock 
on the data segment. This lock prohibits the use of the 
data while it is being updated. When uodating is completed* 
the lock is removed* the update procedure places itself in a 
blocked status to await its next wakeup message* the 
condition handler is exited and execution resumes. 

Use of coordination by interrupt handling may be seen 
in the dynamic updating of positions. When the movement 
moaule changes the location of the unit* an interrupt is 
generated as the movement module is exited". This interrupt 
is converted into a wakeuo that is sent to the display 
routine. The display routine creates the new display and 
then Places itself in blocked status to await the next 
position change. This conversion of interrupts to wakeups 
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not only facititates display but also allows the procedure 
to be active only- as required. Extraneous nonexecuting 
simulation routines need not be in primary storage until 
required for use and disolay routines need not continuously 
draw the same picture in order to prevent missing an event. 
Displays may now be made only as change occurs. 

2 . Rea 1 -t i me v 

Real-time must be aporoached from both the computer 
science and modeling definitions. The computer science real 
time is accomolished by the synchronization mechanisms 
discussed in section A-3. The various programs and 
procedures are forced to run in-steo since they are called 
by wakeups from the main simulation on an as required basis. 
T-h i s system will have least overall detriment to the 
simulation in the model i no real-time sense. Memory 
management may Prove to slow the simulation from paginq 
activities but. proper selection of the orogram's working set 
size will reduce these caging delays to a minimum [Denning 
1968]. A clever operating system will have facitities for 
maintaining the current working set size as a program 
executes. Associative and cache memories will also soeed uo 
execution of the simulation execution due to high speed 
address translation ana reference tSchroeder 19711. The 
mechanisms to synchronize segment usage may cause some 
slowing while procedures are in a blocked status. This 
slowdown will be overcome since separate programs will be 
allowed to execute simultaneously in a mu 1 t i orogr amm i nq and 



83 



mu 1 t i process i ng environment. An example of synchronization 
of segment usage is the calculating line of sight while the 
display of current positions is being oroduced by another 
processor . 

3. Moni tor Program 

The monitor program provides a master control 
facility for the modeler. This monitor program provides the 
main condition handler for the simulation. From the master 
console, any capability of the simulation system may be 
called at any time. Any privileged instructions available 
to the modeler but not the war gamer will be executable from 
this terminal. 

The monitor program will be written as a separate 
program executing on a dedicated display device. All 
modules of the monitor program will be of sufficient 
priority to preempt any of the executing routines of the 
other programs., of the system. 

Tne monitor program is made possible through the use 
of condition handlers and shared data. The monitor program 
will also be capable of placing locks on data files since it 
is capable of writing to data files. Coordination with the 
remaining procedures will be accomplished through the block 
and wakeup mechanisms. The access rights and security 
levels of all procedures will be set by the monitor program. 

4. Dynamic Event Recording 

Dynamic event recording is used to save the execution 
state of the simulation at various decision making points. 
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This state of execution is composed of two distinct carts 
with distinct characteristics. The state of the simulation 
is the set of values of all simulation variables. Whenever 
a decision is input/ the operating system needs to copy the 
data segments containing the appropriate variable values 
onto a secondary storage device. These values must be 
copied prior to any changes due to the input decision. The 
state of the machine is c ha r ac t e r i zed by the values in the 
machine’s internal registers. At the decision point/ the 
operating system saves the reqister values in secondary 
storage. The operating system must then label these values 
and inform the user of the assiqned label and resume 
execution. At some future time when the user desires to 
return to this point/ he need only supply the label value of 



the dec i s i on 


point 


and 


the 


operating 


system 


will 


then 


res t ore 


the 


simulation 


and 


execution 


states/ 


returni na 


corn ro 1 


to the 


user 


for hi 


s new 


decision. 









5. Report Writer 

The purpose of the report writer is to produce 
statistical reports based on stored historical data and 
current Dattle status. It should have the capability to 
produce graph summaries of the user's desired format. For 
instance/ bar graphs may be desired over simple plots for 
certain items. For ease of implementation/ this should be 
defined as a user requirement however the report writer can 
be developed with sufficient flexibility to allow 
interactive user format selection at the expense of I aroer 
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programs. If sufficient storage space (memory or secondary) 
exists and system execution is not sufficently degraded^ 
then this flexibility should be pursued for the benefit of 
the ultimate user . 

The reoort writer is a procedure included in the 
administrative routines program. Prooer selection of ring 
brackets and delegation of access permission will allow the 
report writer to reference data and perform its required 
function. The report writer may be invoked from either the 
administrative program or the monitor program. The invoking 
program sends a wakeup to the report writer to initiate the 
procedure. Uoon completion, the report writer places itself 
in a blocked status to await further use. 

6 » Inqu i r y Mode 

The function of the inquiry mode is to allow 
commanders and their staff sections to auestion the 
simulation. Legitimate inguiries are those that each agency 
would normally initiate during an actual battle. For 
instance the S-l would not be allowed to query directly the 
status of some area outside his cognizance but rather 
require him to communicate via the appropriate agency which 
has cognizance over the area in question. Chapter II, 
section 0 previously identified normal areas of cognizance 
for the staff sections. 

Answers to any agency's reauest must reflect the 
accuracy and timeliness experienced in a true battle. This 
requirement should be handled in the simulation of inter- 
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organi zat i ona 1 communication oaths. Any accurate and 
instantaneous reply' could be misleading to to the commander. 
Human factors must be considered and accounted for in the 
inquiry mode's operation to reflect realism. 

7. Map and Overlay Generation 

Initial terrain generation experiments were conducted 
on a POP 11/50 using a TEKTRONICS. 4014-1 display device as 
the display medium. The 4010 has several disDlay modes 
including point ' and vector. A resulting tutorial was 
developed for use and is included as APPENDIX A. 

Current methods used for generating contour maps from 
stored matrices of data could not be used to display the 
terrain for this simulation CDayhoff 19631. One of the 
advantages of oarametric terrain is that terrain may be 
calculated rather than stored allowina large areas to be 
modeled. Using calculateo terrain, the only altitude known 
is that of the„current location. The decision was made to 
scan the area from South to North and from West to East to 
determine the location of contour lines. The resulting 
problem was that with a constant samoling step size, it 
could not be guaranteed that the step taken would in fact 
fall on a contour line. Next a point was accepted as being 
on a given contour line if it were within a specified 
tolerance from the contour line. This tolerance was 
measured in the vertical direction. The first attempt at 
displaying parametric terrain utilized the point mode of the 
4014. The deficiency noted in this approach was the 
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inability to establish contour lines since the diSDlay image 
consisted of a series of dots. To accomplish the illusion of 
lines a sufficiently small delta x and delta y had to be 
used thus extending execution time for any given piece of 
terrain. If the display wav to be magnified to any degree 
the line illusion became visible dots or points once again. 
This effect demonstrated the heed to draw contour lines 
using the vector mode of the 4014. 

In order to utilize the vector mode* a drawing 
algorithm was developed. The algorithm used to determine 
the direction of draw was guite simple. Once a decision to 
draw was made* all points adjacent to the current point in a 
North or East direction were calculated and the line was 
drawn to the point closest to the contour elevation. This 
approach produced contour bands rather than contour lines. 
These bands were acceptable on steep slopes but in the 
flatter areas Jthey were guite wide. An attempt to reduce 
the number of line segments to be drawn was made by drawing 
to a given point only if the point immediately North of it 
was farther from the contour line than the current point. 
This produced contour lines that were shaded on the North 
side. The solution to this problem resulted in an 
additional condition that a point would not be considered 
for plotting unless it were closer to the contour line than 
both the adjacent points in the North and South directions. 
The resulting map was adeguate but still retained shading 
along a hill's major access in the area of the contour line 
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plus and minus the tolerance. The shading was negligible 
near the peak of the hill, but guite distracting near the 
base. The shape given by the distribution is increasingly 
flatter as one proceeds outward from the center of the hill. 
The solution to this problem was in the calculation of a 
dynamic tolerance. This tolerance was calculated by 

determining the distance f r 'om y hill center that the 

distribution reached three standard deviations or fell below 

some specified minimum altitude, whichever comes first. 

✓ 

This method produces an acceptable mao. The resulting 

algorithm follows: 

1. Locate point closest to contour line. 

2. Sample adjacent points to North and/or East. 

3. Draw line to adjacent point closest to contour 
line. 

4 . Locate next point closest to next contour line. 
The major drawback to this approach lies in 

consumption of time. This method is of complexity of order 
N squared meanjng that doubling the size of the map to be 
displayed roughly quadruples the execution time. This 
routine is by no means real-time in nature. Experiments 
were conducted to speed up the drawing of this contour map. 
The map may be drawn in real-time if the calculations are 
not reguired every time the terrain is displayed. The 
solution reguires that the commands to move and draw that 
are generated by the CPU and sent to the display device must 
be intercepted and written to a data file. Uoon a reguest 
to draw a given area, only the actual move and draw commands 
need be executed. These commands may be created and stored 
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as the terrain is designed and referenced later during the 
simulation as required. 

The ability to draw different sections of the 
battlefield is easily attained. By using a device such as 
the TEKTRONIX 4014 a virtual window may be defined to the 
display. This virtual window is mapoed onto the physical 
display window and only the point's within the virtual window 
are displayed. This virtual window may be dynamically 
created from inout parameters from the console. The contour 
lines may be stored in separate files per individual line 
elevation thus allowing combinations to be plotted and 
giving flexibility of selection of line interval. 

Overlays will be plotted on the basic contour map. 
These overlays may be selected individually or in any 
combination of the available overlays. The use of color 
displays will make the overlays stand out from the map and 
avoid confusion when multiple overlays are reauested. In 
order to avoid destruction of the contour map by overwriting 
from the overlays? the display terminal must have a 
selective erase capability. This will allow the removal of 
a specific overlay without disturbing any others that may be 
displayed at the time of removal. 

8. Security of Classified Data 

Physical security of the classified data during input 
or output remains the problem of the user. The terminals 
used must be in a secure environment to avoid compromise 
before data is entered into the computer and after the 
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classified output is generated. Remote use of the 

simulation will be’ possible if scrambling devices are placed 
on the communication lines. Comput at i ona 1 security is 
provided by the operating system since properly specifying 
the security level of the simulation will cause the internal 
protection mechanisms to safeguard the data from tampering 

within the computer. Thus the simulation running classified 

/ 

data may be described with a security level of 

<c 1 ea ranee t ST AR> and thereoy refuse usage of the data to 
anyone reqardless of c 1 ass i f i cat i on without STAR access. 

9. Library Routines/Tutorials Needed 

In any interactive system certain library routines 
and tutorials make the system more convenient to use. These 
routines lie resident within the system and are capable of 
being called by the user. Several readily identifiable 
examples are discussed in the following sections, 
a. Terrain Generation Package 

The ourpose of the terrain generation oackage is 
to allow the user to define any aiven terrain area in terms 
of the required parameters orior to the execution of the 
battle simulation. The terrain generation package uses the 
identical data items required by the elevation routine of 
the simulation. Once the user has defined the terrain to 
his satisfaction he can elect to creat a file containing the 
display device commands generated during the display phase. 

The terrain generation package includes two major 
itemsf a highly interactive orogram and a tutorial 
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describing the program’s use. The interactive program 
allows the user -to define and display the terrain of the 
battle area. The definition phase includes capabilities to 
build/ modify/ add-to or delete-from a data file containing 
the parameters. Apoendex A defines these allowable 
f unc t ions. 

The terrain display phase allows the user to draw 

/ 

contour lines of his chosen level from the data. The user 
specifies bounds for the display in terms of maximum and 
minimum grid coordinates/ the contour level and the step- 
size desired. The user specified bounds give the illusion 
of zooming-in or away from the terrain. Bounds smaller than 
the defined battle area will cause a smaller area to be 
displayed in the static display window creating a blown-up 
or zoom-in effect. Conversely/ should bounds 1 araer than 
the battle area be prescribed/ a reduction or zoom-out 
illusion is created. All displays are generated without the 
need to store in memory an elevation for each <x f y> 
location. 

The terrain generation program contains the 
following functions. The user is allowed to build the 
parametric data file under a filename of his choosing. He 
is allowed to add/ delete and modify the file to reflect the 
current state of terrain generation. There should be a 
narrative portion which describes the function of the 
program and demonstrates effects of different input 
parameters. The user should also be allowed to familiarize 
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himself with the system by manipulating parameters and 
seeing the results displayed. The capability to plot 

contour lines of the user's desired contour level from the 
defined terrain is also provided, 
b. Position Selection 

The purpose of the position selection package is 
to allow the user of STAR to select defensive positions and 
routes-of *march for his forces. This package/ like the 

terrain generation package/ is primarily a pre-execution or 
set-up operation desiqned to facilitate planning of a 
battle. Execution during the battle will give the user 
insight as to possible new positions or tactics as the 
battle progresses. Since interaction between user and 
simulation is provided for/ the user may desire to utilize 
information gleened from the position selection packaqe to 
perform updates durinq the simulation. 

The„ pos i t i on selection program should use the 
contour mao generated by the terrain generation package and 
determine 1 i ne-o f -s i gh t (LOS) fans for any selected position 
within the battle area. There are two approaches to the 
representation of LOS fans/ each with it's own advantages 
and disadvantages. The first approach is to shade-in the 
visable area in the fan. This method gives the user a 
distinct impression of how much area the fan covers. 
However/ specific terrain c h a r ac t e r i s t i cs within the fan may 
be hidden from the user's view. To counter this 
degredation/ the package should allow the user to display 
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the fan in an inverted mode 



This inverted mode should 



shade the areas outside the LOS fan thus allowing 
to see only geographic features defined within 
These two aDproaches when combined should allow the 
LOS related information concerning that position. 
4.1 and 4.2 depict the results of the two methods. 



the user 
the fan. 
user all 
F i au res 
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Figure 













c. Military Symbol Library 



The ourpose of the military symbol library is to 
allow the user either through his interaction or program 
action to select a series of predefined display device 
commands to draw a standard military symbol. This functions 
somewhat like a table lookuo orocedure where the resulting 
table entries are a series of / entries that define a 
particular symbol. The map overlay disolay programs must be 
able to access this library and retrieve these instructions 
for dynamic disolay during the battle. 

Military leaders are innovative when a standard 
symbol has not been defined for some unique apolication and 
consequently establish some symbol to represent their new 
weapon or unit. The program should allow the user to define 
any additional symbols needed. A standard checker-boa rd 
pattern, such as figure 4.3, should be provided on the 
disolay screen. 



figure 4.3 

The user can select any square and the program will shade 
that area. By continued selection, the user can define a 
symbol of his choosing. After the user has defined the 
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symbol to his s a t i s f ac t i on , the proqram should display the 
symbol for final approval of size and features. The symbol 
may now be stored in the library for future reference. 



C. USE OF THE SYSTEM 

The simulation system will be useful in all phases of 
modelina. A typical senario may "follow this outline. The 
life of a simulation beains with the writina and debugging 
of the code. The simulation imolementer may sit in his 
office and enter the code through a console as opposed to 
punchinq data cards and feeding them into a card reader. As 
the implementer finishes entering the code/ he may now 
compile the program and correct any syntax errors from the 
console. Execution may reveal problems with his code that 
may also be corrected from his console. 

The user of the simulation taxes over after the 
implementer has finished and the model is ready for use. 
The user must first set up tne model for use. This set up 
is facilitated by the tutorials provided by the system. The 
terrain generation package exolains the method of generatinq 
terrain. The user uses this terrain package to generate and 
store the parameter values necessary to create ana display 
the terrain. Using the 1 i ne-o f -s i gh t capability of the 
system/ the user then selects the initial positions for the 
elements on the battlefield using the LOS fans provided by 
the system. 

The modeler is now ready to use the simulation. As the 



98 



simulation progresses* the user is able to monitor the 
simulation and decide when to interact with the simulation. 
Should he decide to interact* he may do so from his console 
by pressing the ATTN key and selecting the type of 
interaction desired from the menu of possible alternatives. 
Once the interaction is accomplished* the simulation 

continues. The user notes the effect of his interaction and 

/ 

wonders if the outcome would change had the interactive 
input been different. He elects to return to the point of 
input and experiment with a different course of action. 
Again* he presses the ATTN key and this time he chooses the 
option to repeat the simulation from a specified point. 
Having changed his inout* the user elects to continue with 
the simulation. The simulation continues until termination. 

Post execution analysis is accomolished through the 
creation of written reoorts by the report writer and the 
answering of questions by the inquiry routine. At this 
point the user may still elect to investigate behavior by 
returning to a given point and resuming execution. Upon 
completion of analysis* the user may elect to destroy the 
simulation files. 
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V. ANALYSIS OF CURRENT STAR 



A. GENERAL 

The analysis conducted on the current version of STAR 

was performed in the general areas of program structure? 

/ 

control structure? storage optimization and suoroutine 
analysis. Certain guidelines were used in the analysis of 
the current version of STAR. The proaramming language used 
is SIM SCRIPT. The methodology used in the simulation will 
be left to the programmer and comments will be limited to 
programming technigues. 



B. STRUCTURE 

The SIMSCRIPT programming language has the capability to 
be both readable and structured. Readability and structure 
allow the program to be maintained by persons other than the 
original writers. This capability of the language is not 
being fully exploited. Good readaoility facilitates ease of 
maintenance and debugging. To attain the desired level of 
readability several principles must be followed. 
Indentation should be present to offset the control 
structure from the code that is contained within that 
structure. For example? should the "if" in an "if else" 
structure be indented five spaces? the "else" should also be 
indented the same number of spaces. Only one source 
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statement should be allowed to a line. All local variables 
should be defined rather than allowing the default values of 
SIMSCRIPT to take orecedence. Variable names should be 
obvious as to their representation* since SIMSCRIPT allows 
long variable names. Many cases of short variable names 
occur in the STAR orogram either through ease of use or bad 
programming practices. These shorter names contribute to 
ambiguity and confusion. One example of lack of structure 
is seen in the following code ' extracted from the current 
mode 1 : 

until jji = If do 

let t a rge t ( name ( t an k ) , 2 . ) = he.draq(tank) 

let he . dr ag ( t an k ) = 0 let mv . s t a t e ( t an k ) = 1 
let defnum(tank) = 1 

let jji = jji + 1 1 oop 

This code will be more readable if it were structured 

similar to the following: 

until jji = 1» 
do 

let t arget C name ( t ank ) , 2 . ) = he . drag ( t ank ) 

let he . dr ag ( t ank ) = 0 

let mv . s t a t e ( t an k ) = 1 

let defnum(tank) = 1 

let jji = jji t 1 

1 OOP 

This type of structure has two major benefits. Programmers 
easily recognise the scope of the UNTIL statement and the 
assignment statements are readily found since they are one 
per line and begin with the reserved word LET. 

Another example of how structure may lead to 
understanding is found in the following segment of code from 
the routine CHG . SEC . SEARCH . 
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"dl " 



if cssCa) = 1 
• go to dll 
else 

go to d 1 2 

"dll" 

let ori.dir(a) = pi. c/2 
let css(a) = 0 
qo to set 

" d 1 2 " 

let zyx = uni form, f (0. » 1 . , 1 ) 
if zyx ge .5 

go to dl3 

else 

go to d 1 4 

" d 1 3 " 

let pri.dir(a) = p i . c / 4 
let cssCa) = 1 
go to set 

" d l a " 

let ori.dir(a) = 3 * p i . c / 4 
let css(a) = 1 
go to set 

"set " 



Upon examininq this unstructured version of STAR source 
code, it is evident that it may be replaced by the following 
sequence : 



"dl "' 

if css(a) = 1 

let pri.dir(a) = oi.c/2 
let cssCa) = 0 
go to set 

e 1 se 

let cssCa) = 1 
if un i f o rm . f C 0 . , 1 . , 1 ) ge .5 
let pri.dirCa) = pi. c/4 
qo to set 

else 

let ori.dirCa) - 3 * p i . c / 4 

"set" 



This code sequence is easily understood ana has - two 
additional benefits. First, this structured code will 
execute faster due to fewer transfers of control. Second, 



1 02 



storage requirements are reduced since this version has 
fewer lines of source code , thirteen instead of twenty- 
four, thereby reducing object code storage requirements and 
does not require the variable "zyx". 



C. CONTROL STRUCTURES 

The STAR model needs extensive optimization in the area 
of control structures. The following example is from the 
routine COMMO.PASS.TGT. 



if pet. vis gt c r i t i c a 1 . va 1 ue 
let lose = 1 
jump ahead 

else 

let lose - 0 

here 

if lose eq 0 

let aim = 0 
return 

else 



This code sequence is equivalent to the following: 



if pet. vis 1 e c r i t i ca 1 . va 1 ue 
let aim - 0 
return 

else 



The sequence may be reduced even further if the variable 
" aim** is initialized to zero since this is the majority of 
usage ("aim" is set to zero four times as opposed to one 
only once). This saving in storage of object code, ease of 
understanding and execution speed-up is attained by testinq 
"less than or equal to" as opposed to "greater than". This 
particular type of control structure is used in other places 
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in the program as well 



Another common control structure abuse is observed in 
the routine RES4. This routine has seven "do loops"? all 
indexed from 1 to 2. These loops may be combined into one 
control structure which will result in a reduction in 
execution time (counter maintenance) and a saving in object 
code storage. The combination of "do loops" is possible in 
the majority of the STAR routines. 

Another optimization technique applies to the routine 
PRIORITY. AND. ROUND. SELECT with the follwing code seauence: 



1 et i = i -1 

go to iO? i 3 r i6? i9, il2 per i 

" i 0" 

let i = 0 
go to bands 

" i 3" 

let i =3 
go to bands 

" i 6 " 

let i =6 
„ go to bands 

" i 9" 

let i = 9 

go to bands 

"i 12" 

let i = 12 
go to bands 
"bands" 



A little "cleverness" reduces this sequence to 
i = (i - 2) * 3 

In fact? in this routine alone? fifty-four lines of source 
code may be reduced to four lines without loss of meaning. 
Benefits of the reduction include ease of understanding? 
more efficient execution and less storage requ i remen t s . 



0. STORAGE OPTIMIZATION 



Storage 


optimization can occur 


i n 


several 


ways 


in the 


STAR model 


. Append i ces C 


and 


0 


present 


the 


storage 


regu i remen t s 


of the current 


uns t rue t u red 


model 


. The 



"complexity” item under each routine analysis in Appendix B 
indicates storage dependencies. 

Another area that deserves .close monitoring is tne 

✓ 

assignment of subscripts in arrays. An example of this 
detrimental effect is seen in the array called TARGET. The 
actual variable is T ARGET ( 32 1 / 2 ) . SIMSCRIPT creates a data 
structure with 321 pointers to vectors of length 2. By 
reversing the subscripts giving TARGET (2/321) the SIMSCRIPT 
compiler stores this with 2 pointers of length 321. This 
reversal of subscripts saves 319 words of storage or 1278 
bytes of memory. If at all possible/ suoscriots should be 
arranged with the smallest first and in increasing order. 

Appendix 0 gives a summary of all static storage arrays 
and the storaae reaui red if an optimal assignment of 
subscripts is used. By this use of optimal subscripts 
approximately 12K bytes of storage may be saved. 

E. SIMSCRIPT ROUTINE ANALYSIS 

The SIMSCRIPT routine analysis was performed after a 
structured version of STAR was produced. All names are 
alphabetical within their category. For each subroutine the 
following items were identified: 

1. Parameters passed to the subroutine. 
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2. Local variables defined to that subroutine. 

3. Global variables accessed. 

4. Variables read into the subroutine. 

5. Variables written to print. 

6. Data structures created. 

7. Data structures filed into a predefined set. 

8. Data structures removed from a set. 

✓ 

9. Data structures destroyed. 

10. Vectors or matrix for which storage is 
reserved. 

11. Vector or matrix for which storage is released. 

12. Other subroutines called. 

13. Subroutines that call the subroutine. 

14. Events scheduled. 

15. Subroutine that schedules the event. 

16. Complexity of suoroutine in regara to 
execution time ana storage requ i r emen t s . 

17. Recommended imDrovements (excluding general 
improvements identified earlier). 

18. Any remarks concerning the subroutine and 
values returned to the calling program. 
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V r . CONCLUSIONS AND RECOMMENDATIONS 



The STAR war gamino model is written using sound 
modeling techniques. The i mo 1 emen t a t i on does have a serious 
drawback in maintainability. without structure? this 
program is difficult? at best? to understand and will be 
extremely difficult for anyone other than the actual code 
writers to maintain. The current version of STAR is at this 
time undergoing extensive modification to give the program 
structure and to attempt to gain efficiency to both storage 
and execution. 

This thesis is a oreliminary design and therefore only a 
preferred solution was given. As the preferred solution is 
developed at a later time? more detail may be given as to 
the final implementation of the STAR mooel. The 
implementation-of STAR using the OPeratinq system approach 
may be attempted here at the Naval Postgraduate School. The 
features described that are necessary to implement the 
proposed enhancements are found in the MULTICS operating 
system from Honeywell Information Systems? Inc. which is 
available on the ARPANET. This availability gives the 
school the opportunity for further study. 

One of the most beneficial short term improvements that 
can be made is to obtain an interactive SIMSCRIPT compiler. 
The interactive compiler may be obtained free of charge f rom 
Consolidated Analysis Centers? Inc. unoer the university 
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grant oroqram 



Further experidientation with graphical displays may be 
made at the Naval Postgraduate School utilizing the research 
comouter in the school graphics laboratory. This comouter 
may be used as a remote terminal to the w.R. Church Computer 
Center and graphics disolays oroducea on the terminals in 
the 1 aboratory * 

✓ 

The STAR wargame orovi les excellent oooortuni ty for 
further computer science thes.is work. Additional thesis 
material may include optimization of terrain disDlay usinq 
the oarametric method of terrain reoresent at i on . Thesis 
work in the area of ooerating systems may include actual 
implementation of the STAR model on the ARPANET. Work in 
the dataoase area will be required to develoo the inquiry 
capability and tne reoort generator. 



APPENDEX A 



AN INTRODUCTION TO INTERACTIVE TERRAIN REPRESENTATION 
UTILIZING PARAMETRIC TERRAIN GENERATION 

I. INTRODUCTION v 

/ 

This tutorial has been develooed to allow interactive 
use of parametric terrain generation* Currently mechanisms 
exist for ouildina and modifying the incut file required for 
the generation of terrain features and displaying contour 
lines of the user’s desired level. Due to modular design/ 
further terrain enhancements such as three-dimensional views 
from any ooint may be developed and incorporated into the 
existing program* 

Parametric terrain generation uses as inout parameters 
the x and y locations of the center of the hill (xc and yc)/ 
the elevation at that <xc/yc> location (peak)/ tne 

eccentricity of the hill (ecc) / the height of the 

parameter i zed hill (ht)/ the angle of rotation of the hill 
from an East-West axis (angle) and the spread of the hill 
(sprd) . For each set of hill values there is a base 
altitude/elevation (dasealt) associated. This base altitude 
is the elevation of the lowest ooint in the terrain area 
that is being modeled. The eccentricity of the hill (ecc) 
is tne ratio of major axis to minor axis (major-axis/minor- 
axis) for the hill under consideration. The spread of the 
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hill is considered to be the distance along the major-axis 
for the elevation to drop fifty (50) meters. Fiqures A-l.l 
through A-1.5 graphically explain these parameters. 




spread 



FIGURE A-l.l 




FIGURE A - 1 . 2 




FIGURE A— 1.3 




FIGURE A-l.tt 




FIGURE A-1.5 



II. HARDvVARE REQUIREMENTS 



A. INTRODUCTION 

The display hardware utilized in the development is 
centered around the TEKTRONICS 4014-1 storage tube graohics 
display system. It has a 19 inch storage tube as a display 
medium. Associated with the 4044 is a standard ASCII 
keyboa r d . 

A VERSATEC MATRIX printer is accessable through the 
PDF 11-50 and allows hard copy generation from the 4014 
disolay. A hard copy of the 4014 display screen can be 
obtained by depressing the copy key located on the upper 
right portion of the keyboard. 

The PDP 11-50 with the UNIX timesharing system is 
utilized and assumes the 4014 is a conventional alphanumeric 
CRT allowing the user to M login 11 normally. Section IV 
discusses these "login" procedures. 



B. SYSTEM OPERATION 

The 4014 is powered on by turning the off-on switch, 
located under the keyboard about one foot from the floor, to 
the on position. After turning the device on, wait 
approximately 30 seconds before proceeding to allow the 
device to warm up. The screen will appear a bright green and 
now must be erased by depressing the page reset key on the 
upper left portion of the keyboard. Should a residual image 
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appear on the screen* wait aoo rox i ma t e 1 y 15 seconds and 
depress the page reset key once again. Insure that the mode 
toggle* located above the page reset key* is in the online 
position rather than local. Depress the carriage return and 
wait for the UNIX timesharing system to request "login”. 
Follow normal PDP 11-50 login procedures. 



III. DESCRIPTION OF PROGRAM FUNCTIONS 



A. MAIN 

The main program requests the name of the data file 

that the user desires to operate on durinq this terminal 

session* The user enters the filename* upon request in 

either upoer or lower case letters* that he either desires 

to use or create. The filename is limited to eight 

characters but the user may specify any length filename and 

the oroqram will only use the first eight* terminating all 

others. For this reason the first eight characters of any 

filename should be uniaue. If the filename is not an 

exist inq file* the program will create it for the user. If 

the file does exist* the program will open that file for 

# 

read and write access to the user. A command list is 
displayed next to allow the user to select that function he 
desires ana enter the aoprooriate command code when promoted 
by the program. The main proqram is developed around a CASE 
statement to allow the user to perform his desired 
functions. Control remains in this CASE statement until the 
user elects a code of M 7" to terminate the session. When 
the user selects code 7 the program displays the current 



state of the 


data file 


that 


the user selected 


du r i ng 


the 


beg inning of 


the 


session on 


the 


40 1 4 and uoaat es 


the 


file 


for f uture 


use 


. Should 


the 


user not desire to 


retain 


the 


current copy 


o f 


the file. 


he 


may exit the 


proaram 


by 


depress i ng 


the 


rub-out key 


located on the 


lower r 


i gh t 



portion of the keyooard. (This method of program termination 



is not recommended as a short-cut however*) 



B. ADO 

The add function allows the user to add another set 
of hill values to the data file specified in the beginning 
of this terminal session. Add it Ton of hill values is 
accomplished by addinq them to the end of the data and 
incrementing the number of hills on the file. The program 
will prompt the user for each data item required for the 
hill and give the user the option of adding multiple hills 
or only a sinqle hill. All hill values are floating point 
numbers* however* the user neea not specify a decimal ooint 
if that value is a whole number since the program is capable 
of i nterpret at i on in this case. 



C. BUILD 

The build function gives the user the capability to 
initially build the file specified during the beginning of 
the terminal session. Care must be taken to prevent 
building a file that already exist since the building 
process will over-write all data previously resident on that 
file. Building is accomplished by requestina from the user 
the number of hills he desires to load to the file. Next 
the program will prompt the user as in the add function for 
all neccessary hill values. The program will allow the user 
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to only build one file oer terminal session. However» 
should the user desire to ouild multiple files he may do so 
by building the first one and then enter a command code of 
"7" to exit the oroaram. Subseauent file building is 
accomplished by repeating this same procedure. 



0. CHANGE 

The chanae process is actually a modify process since 
it allows the user to change or modify any single hill data 
item or all data items for a hill. The program prompts the 
user for the hill number he desires to change* allows the 
user to select the data item to be cnanqed and then requests 
the new value that is to be substituted. The change function 
will allow the user to change one hill or many hills by 
asking the user if he has any more changes. 



E. OELETE 

The delete function allows the user to delete a 
complete set of hill values for the hill number specified 
from the data file. Deletion is accomplished by requesting 
the number of the hill that the user desires to delete* 
locatina that set of hill values and shifting all higher 
hill number values down* overwriting the deleted hill and 
decrementing the number of hills. It is recommended that if 
multiple hills are to be deleted* the highest hill number be 
used first to prevent the user from losing track of the 



current 



hill numbers since the deletion process also 



logically decrements the hill number. Multiple deletes may 
be accomplished since the program will ask the user if he 
desires to delete another hill. 



F. PLOT 

The plot function uses the parametric input data, 
which is located on the file specified by the user, and 
generates contour lines of the user specified contour 
interval. The program prompts the user for the minimum and 
maximum x locations, the minimum and maximum y locations, 
the contour interval desired and the minimum elevation in 
the area to be displayed. 



G. MISCELLANEOUS 

The first miscellaneous routine to be discussed is 
the " w r i t e f i 1 e M routine. This routine restores/^r i tes the 
hill data from memory to a secondary storage (disk) file for 
suoseauent use by the user. The number of hills is written 
first followed by all x locations (xc). The file structure 
is completed by writing the entire y locations (yc )/ hill 
spread values in the x direction (sx), spread values in the 
y direction (yc) , the rotation values respectively and 
closing the file. 

The "readfile" routine functions like the ” w r i t e f i 1 e n 



function but loads the hill values from the secondary 



storage (disk) file into memory. The filename used is that 
specified by the * user at the beqinninq of the terminal 
session. 

The "printfile” routine displays to the 4014 the hill 
data located in memory starting with hill number one and 
continuing to the number of hills that are beinq used in 
this session*. 

/ 

The " invalidcmd H routine oroduces aoproori ate error 
messages to be displayed on the 4014 for the user. The user 
must heed the error message and take appropriate action 
accordinql y. 

The "cmdlist" routine displays all function codes to 
the user. It is from this list that the user must select 
the command code cor resoonci nq to the function desired and 
enter it when oromotea oy the program. All commands must be 
followed by a carriage return. 



IV. SYSTEM USE 

To initiate the program execution after powering on the 
4014 the following procedures must be followed. The first 
step is to login to the UNIX system with a name of "parry” 
and a password of "parry”. (Note all entries are lower case 
letters.) The second step is to enter "terrain" followed Dy 
a carriage return and the program will begin execution 
prompting the user as needed to step the user through the 



reaui red procedures 



APPENDIX B 



AMMO .CHECK 

NUMBER BYTES OBJECT CODE : 49b 



PARAMETERS : 

a rnd 

LOCAL VARIABLES : 

a answer 

rod 

GLOBAL VARIABLES : 
ap . t ow 
aw2.or.adm 
c .2 

wpn .type 

CALLED BY : 
priori ty.and. round. sel ect 
t72. tactics we. miss 

COMPLEXITY : Constant storage requirement and execut 

time. 

REMARKS : This routine returns the value of answer to 
calling rout i ne . 



awl .or.msl 3 
c . 1 

he .drao 



i on 
the 



ARTY . IMPACT 



NUMBER BYTES OBJECT CODE : 1312 



PARAMETERS 



i d . b t r y 


i d . f dc 


i d . f o 


i d . m i ss i on 


ABLES : 


an s 


estimate. of 


i 


i d . b t r y 


i d . f dc 


i d . f o 


id.fnission 


j 


k 


A 


m 


rg 


t i me 


t i me . 1 


t i me . 2 


t i me . 3 


t i me • 4 


t i me . 5 


t i me . 6 


t i me . 7 


within. tolerance 


X X 



yy 



GLOBAL VARIABLES : 
cal i be r 
de 1 . I 

error .code 
gt . f i na 1 . rg 
miss. tolerance 
m s n . t i m e 

no.missions.fi red 
num . ad j . rounds 
rate. of. fire 
rd. 2. error 
t het-a 
vo 1 ley 

which.vol ley 

x. cur4 
y .cur 1 

y . future. 1 oc 



WRITES : 

i d . f o 
i d . f dc 

vo 1 leys.to.fi re 
w i t h i n . t o 1 e ranee 



debuq 
del .2 
gs rs . code 
last.fo.rg 
msn . name 
my . r ad i o 
now.fi ring 
num . dp i cm . left 
rd . 1 . error 
St . f i r i nq 
t i me . v 

vol leys.to.fi re 
x . cu r 1 

x . f ut u re . 1 oc 

y. cur4 



i d . b t ry 
msn .name 
num.aaj .rounds 
t i me . v 
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ARTY. IMPACT (cont) 



CALLS : 

arctan.f 

assessment 

error 

position. upda t e 
p r i n t 1 

SCHEDULES : 

busy. radi o.net 
guns .firing 

SCHEDULED BY : 

guns .firing 

COMPLEXITY : Execution is 
constant storage. 



arty. time 
di st 

new . 1 oc a t i on 
print 
t racer 



end. of. miss ion 
open.radio.net 



linear on volleys. to. fire 



ARTY. TIME 

NUMBER OF BYTES OBJECT CODE : 416 



PARAMETERS : 

a 

LOCAL VARIABLES : 

a de 1 . t i me 

GLOBAL VARIABLES : 

f a . t i me . de 1 t as rn. stream 



CALLS : 

norma 1 . f t racer 

uni form, f 

CALLED BY : 

a r t y • i moac t 

check ing. guns. avai labi 1 i ty 

commo . a t t emo t end . o f . m i s s i on 

f dc .processi ng update.c 1 uster 

COMPLEXITY : Constant execution time and storage. 

REMARKS : Returns the value of del. time to the cal 
routine. 



but 



i nq 
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ASSESSMENT 



NUMBER BYTES OBJECT CODE : 4528 



PARAMETERS : 



i d . b t ry 
i d . f o 



i d . f dc 
i d . m i s s i on 



LOCAL VARIABLES : 
count 

d i fference 
i d . b t r y 
i d . f o 

j 

1 

ok 

s i g. y 
x .error 
x d i f 

y .change 

y. normal .error 

ynew 

GLOBAL VARIABLES : 

a 1 i ve .dead 
amt. of. hits 
debug 

d i sp 1 acement 
f .d 
f ki 1 I 

gt. final .rg 
kki 1 1 

lethal .radius. array 
m . d - 
mk i 1 1 

num .do i cm . 1 e f t 
num . he . 1 e f t 
p . punc h 
rn . s t r earn 
t i me . v 

x . current 
x .mp i 

y . future. 1 oc 

z . current 



debug .count 
i 

i d. f dc 
i d * m i s s i o n 
k 
m 

S i q . x 
x .change 
x. normal .error 
x new 
y . e r ro r 
y d i f 



ammunition. type 

cal i be r 

de f num 

d . r ad i us 

f i red . a t 

foe 

hit. state 

largest. num. wpns 

level .of. damage 

m f k i 1 1 

msn.name 

num . guns 

num .hit 

rd.of f set 

theta 

wpn .type 

x . future. 1 oc 

y. current 
y . mp i 
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ASSESSMENT (cont) 



WRITES : 




ammun i t i on . t yoe 


cal i be r 




de f num 


d i f f e r enc 




f . d 


f i red . at 




f ki 1 1 


gun t ube 




hi t .state 


i 




k k i 1 1 


m . d 




m f k i 1 1 


mk i 1 1 




name 


nc ase 




num . h i t 


spd 




t i me . v 


/.current 




y .current 


z .current 


RESERVES 


• 

• 

rd. offset 




RELEASES 


• 

• 

rd. offset 




CALLS : 




abs . f 


atrit 




d i st 


1 oc 




new. coordinate. system 


normal . f 




oaramet e r s 
p r i n t 1 


print 



CALLED BY : 

a r t y . i moac t 

COMPLEXITY : Execution deoenaent on num. guns and tank in 
red. .alive. Storaae aeoendent on ) a rges t . num . wpns . 

IMPROVEMENTS : Reverse subscripts on rd. offset. 
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ATRIT 



NUMBER BYTES OBJECT CODE : 2256 



PARAMETERS : 





e f k i 1 1 


emk i 1 1 




kayki 1 1 


sh . t 




tgt . t 


whoc a 1 led 


LOCAL 


VARIABLES : 






e f k i 1 1 


emk i 1 1 




f now 


k a y k i 1 1 




mnow 


pk 




sh . t 

whoc a 1 led 


tgt • t 


GLOBAL 


VARIABLES : 






al i ve.dead 


damage • num 




f . d 


m • d 




m f k i 1 1 


m i ne • de t 




mk i 1 1 


oh 


WRITES 


• 

• 






e f k i'l 1 


emk i 1 1 




f .d 


f ki 1 1 




kay k i 1 1 


m • d 




m f k i 1 1 
pk 


mk i 1 1 


CALLS 


♦ 

• 

uni form.f 




CALLED 


BY : 






assessment 


geom 




m r 1 . i moac t 
red.arty.fi res 


poo • a • m i ne 



SCHEDULES : 

final .aeath 

COMPLEXITY : Constant execution time and 

r equ i r emen t s . 



storage 



ATTRITION. CHECK 



' NUMBER BYTES OBJECT CODE : <196 

GLOBAL VARIABLES : 
b.pct .att 
n . b 1 ue . a 1 i ve 
rc .count 
r.num.al ive 

CALLS : 

i n t . f 

SCHEDULES : 

attrition. check stop. simulation 

SCHEDULED BY : 

at t r i t i on .chec k main 

COMPLEXITY : Constant execution time and 

requ i remen t s . 

BASIC. LOAD 

NUMBER BYTES OBJECT CODE : 20B8 



del t a . t 
n.red.al ive 
r.pct .att 



PARAMETERS : 
a 



LOCAL VARIABLES : 
a 

GLOBAL VARIABLES : 
ao. tow 
c . 1 
capds 
casene 
he .drag 
m 1 
m3 

op . rng 

CALLED BY : 

b 1 .create 



aw 1 . o r . ms l 3 
c . 2 

caseao 
cheat 
h t o 
m2 

name 

wpn . t yoe 



red. create 



COMPLEXITY : Constant storage and execution time. 



storage 
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8L. CREATE 



NUMBER BYTES OBJECT CODE : 2824 



LOCAL VARIABLES : 
i 

GLOBAL VARIABLES : 

ao. tow 
b .num . a 1 i ve 
cocdr 
de f num 
guntube 
mv. state 
OD . rng 
pi .hat 
p 1 1 1 d'r 
p r i . d i r 
r . con 
sec 

veh . t ype 
x. current 

z. current 

READS : 

bn 

cocdr 
name 
p 1 1 1 d r 
sec 

won . t ype 
y .cur rent 

CREATES : 

tank 

FILES : 

tank in blue. alive tank in como.unit 

tank in pit. unit tank in tanks 

RESERVES : 

list 

RELEASES : 

bl .create 

CALLS : 

basic. load elev 

h i de r 

CALLED BY : 

main 

COMPLEXITY : Storage and execution deoend on num. alive. 



bn 

co 

color 

di r.of.mvmt 

y i s t 

name 
P i . c 
o 1 t 

pointer 
rc .count 
r r rpo i n t 
target 
won . t yoe 
y .cur rent 
2 h 



CO 

di r.of .mvmt 

P 1 t 

o r i . d i r 
veh.tyoe 
x. current 
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BMP. TACTICS 



NUMBER BYTES OBJECT COOE : 26a 



PARAMETERS : 
a 

LOCAL VARIABLES : 
a 
b 

GLOBAL VARIABLES : 
co 
foe 



b 



answer 



comp .unit 
tank 



CALLED BY : 

t arget .select 

COMPLEXITY : Constant storage but execution time is 1 
dependent on the number of tanks in como.un 

REMARKS : This routine returns the value of answer 
calling rout i ne . 



PARAMETERS : 
a 



BUG. CHECK 

NUMBER BYTES OBJECT CODE : 102 a 

b 



LOCAL VARIABLES : 
a 

be 

GLOBAL VARIABLES : 
co 

defnum 
mv . st at e 
range 
t . spd 



b 



comp . un i t 
m2 

o 1 t . un i t 
tank 

wpn . t yoe 



CALLS : 

^ dr . mount 

CALLED BY : 

impact 

SCHEDULES : 

df .change 



COMPLEXITY : Constant storage but execution in 1 
dependent on tanks in comp. unit 



i nea r 1 y 
i t 

to the 



inearl y 
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BUSY.RADIO.NET 



• NUMBER BYTES OBJECT CODE : 240 



PARAMETERS : 

i d . r ad i o 




LOCAL VARIABLES : 
i d . rad i o 




GLOBAL VARIABLES : 
state3 




CALLS : 

t race r 


/ 


SCHEDULED BY : 

arty . i mpact 


quns .firing 


COMPLEXITY : Constant 

regu i rement s . 


execut ion time 



s t o rage 
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CAROIO 



•NUMBER BYTES OBJECT CODE : 1200 



PARAMETERS : 



a 


b 


pc t . v i s 


r 


X 

LOCAL VARIABLES : 


a 


ang 1 e 


area 


at 


b 


bt 


dd 


denom 


det.time 


1 ambaa 


mt 


o • sub . k 


pc t . v i s 


pe r • f u 1 1 .ex 


r 


r r 


t.c. factor 


tgt .el ement 


GLOBAL VARIABLES : 


b .area 


blue 


cbar 


color 


di r.of.mvmt 


pi .c 


pi .hat 


p r i . d i r 


r . a rea 


red 


sod 


x. current 


y. current 


z 1 


CALLS : 


abs . f 


a rc t an . f 


1 og . e . f 


s i n . f 


CALLED BY : 

s t ep . t i me 


COMPLEXITY : Constant 


execution time 



requ i rement s . 

IMPROVEMENTS ! All local variables need to be defined 

REMARKS : Returns the value of det.time to the 
routine. 



storage 



cal 1 i ng 
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CHARGE 



NUMBER BYTES OBJECT CODE : 2152 



PARAMETERS 



LOCAL VARIABLES 





avgxc 


a vgx 5 




a vgx 6 


avgx 7 




avgyc 


avgy5 




avgy6 


avgy 7 




c 


- cc 




k 


V 




m 


xc 




x5 


xfe 




x 7 


yc 




y5 

y7 


y 6 


GLOBAL VARIABLES : 






bn 


red.al ive 




tank 


xc 


CALLS : 


x. current 

y . current 

get .uo 


yc 


SCHEDULES 


• 

• 

c ha rge 




SCHEDULED 


BY : 






charge 


1 eave. check 


complexity 


: Executi 


on time is linear on number tanks 




red.al ive. 


Storage requirements are constant. 



i n 
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CHECKING. GUNS. AVAILABILITY 
NUMBER BYTES OBJECT CODE : 1824 



PARAMETERS : 



i d . b t r y 
i d . f o 



i d . f dc 
i d.mi ss i on 



LOCAL VARIABLES : 
i d . b t r y 
i d . f o 
time 



i d . f dc 
i d . m i ss i on 



GLOBAL VARIABLES : 
bt ry 

f i re .di r .center 
msn.name 
num.adj .rounds 
queue . size 
state 
st.fi ring 



debug 
1 abe 1 
msn . t i me 
num . m i s s i ons 
queue . t i me 
stat e 1 
t i me . v 



WRITES : 

i d . b t r y 
i d . f o 
state 



i d . f dc 
msn . name 
t i me . v 



FILES 



id. mission in how i t zer .queue 



CALLS : 

a r t y . t i me 



t racer 



SCHEDULES : 

guns .firing 



SCHEDULED BY : 

f dc .process i nq 



COMPLEXITY : Constant execution time and 

requ i remen t s . 



s t o r age 
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CHG. SEC. SEARCH 



■NUMBER BYTES OBJECT CODE : 1304 



PARAMETERS : 



a 



LOCAL VARIABLES 



a 

zy x 



x y z 



GL08AL VARIABLES : 



b 1 ue 
css 



- color 
d'Tr.of.mymt 
pr i .di r 



mv . state 
pi .c 



CALLS : 

set. sector uniform. f 

CALLED BY : 

st eo . t i me 

COMPLEXITY : Constant execution time and storage 

requ i remen t s . 

IMPROVEMENTS : Meeds to oe rewritten to save 44 lines of 
source code. 
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COMMO. ATTEMPT 



.NUMBER BYTES OBJECT CODE : 1096 



PARAMETERS : 

id.fo id. mission 

i d . r ad i o 



LOCAL VARIABLES : 





id.fo 
i d . r ad i o 


i d . m i s s i on 
time 


GLOBAL VARIABLES : 

error .code 
st ate3 
wa i t . t i me 


i'd 1 e 
t i me . v 


FILES : 


id. mission in msn. queue 




CALLS : 


a r t y . t i me 


t racer 


SCHEDULES 


• 

• 

commo .attemot 
open . radi o . net 


f dc . processing 


SCHEDULED 


BY : 

commo .at tempt 





COMPLEXITY : Constant execution time and 

r equ i remen t s . 



s t o rage 
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COMMO.PASS.TGT 



• NUMBER BYTES OBJECT CODE : a88 

PARAMETERS : 
a 

LOCAL VARIABLES : 
a 

ba i m 
r 

GLOBAL VARIABLES : 
bwd. 1 ook 
foe 

oo . png 
pi t 

CALLS : 

di st 1 oc 

sight 

CALLED BY : 

t72. tactics 

COMPLEXITY : Constant execution time and 

requ i remen t s . 

REMARKS : This routine returns the value of aim 
calling rout i ne . 



critical .value 
f wd . 1 ook 
p c t . v i s 



a i m 
lose 



storage 
to the 



1 3a 



COMPUTE 



NUM8ER BYTES OBJECT CODE : 3528 



PARAMETERS : 

f .pc v i s 
sh . t 

LOCAL VARIABLES : 
adde f 1 
de f 1 b i as 
e 1 b i as 
f . dc v i s 
i o 
k 

pc . v i s 
sh . t 
ve 1 

GLOBAL VARIABLES : 
acc h t 
accmb 
addon 
h t . mov 
sod 

x .current 

WRITES : 

i 

1 

CALLS : 

d i st 
m i n . f 
t rune . f 

CALLED BY : 

i mpac t 

COMPLEXITY : Constant 

requ i remen t s . 



pc . v i s 
t gt . t 



adde 1 
def 1 s i g 
e 1 s i g 
i 

S 

J 

1 

r 

tgt • t 



accke 
accms 1 
bm • mo v 
P r o j o 
wpn • t ype 
y .cur rent 



k 



geom 
subc a 1 



execution time and 



s t o rage 
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CONVERT .BACK 



NUMBER BYTES OBJECT COOE : 712 



PARAMETERS : 





a 




LOCAL 


variables : 






a 


pi . i n t 


GLOBAL 


VARIABLES : 






c .bar 


cba r 




de f num 


dj r.of.mvmt 




d . num 


m . det 




micro 


m i ne . de t 




p . hat 


p 1 .c 




pi ow.cond 


P . v 




spd 


t i me . v 




t . spd 


v .ms 




x.ct 


x. current 




y .ct 


y .current 




z . c t 
zh 


z .current 


CALLS 


• 

• 

pop. a. mi ne 




CALLED 


BY : 

1 oc 




COMPLEXITY : Constant 


execution time 



regu i remen t s . 



storage 
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DECREMENT. AMMO 



‘ NUMBER BYTES 


OBJECT CODE : 768 


PARAMETERS : 
a 


rnd 


local variables : 

a 


r nd 


GLOBAL VARIABLES : 
ap . t ow 
aw2 .or . adm 
c . 2. 

he .drag 
won .type 

CALLED by : 

fire 


awl .or.msl 3 
,c . 1 
erf 
t r f 



COMPLEXITY : Constant storage and execution time. 
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DEFEND 



NUMBER 

PARAMETERS : 
a 

LOCAL VARIABLES : 
a 


BYTES OBJECT CODE : 688 


GLOBAL VARIABLES : 

alive .dead 
de f num 
mv . s t a t e 
p i .c 
sod 

t i me . v 
wpn . t ype 


ap.tow 
f a 

/ 

name 
or i . d i r 
t a rget 
t . spd 


CALLS : 

di smount .dragon 
set . sec t o r 

CALLED by : 

1 oc 


h i de r 



COMPLEXITY : Constant storage and execution time. 
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DETECT 



NUMBER BYTES OBJECT CODE : 792 



PARAMETERS 



a 



b 



LOCAL VARIABLES : 



a 



b 



whoca 1 led 



GLOBAL VARIABLES : 



a 1 i ve .dead 
critical .value 
fa 

f ki 11 

1 ine. of. sight. exists 



bwd . 1 ook 
' de fnum 
f i D 

f wd .look 
oc t . v i s 



CALLS : 

list .update 1 oc 

pro* i m i t y . de t ec t sight 

t r ace r 

SCHEDULED BY : 

impact step. time 

COMPLEXITY : Constant storage and execution time. 
IMPROVEMENTS : Delete the variable whocalled - declared but 



unused 
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DF.CHG 



‘ NUMBER BYTES OBJECT COOE : 496 



PARAMETERS : 
a 

LOCAL VARIABLES : 

a c 

GLOBAL VARIABLES : 

a 1 i ve . dead . color 

defnum 'sod 

CALLS : 

h i d e r 

SCHEDULED BY : 

bug. check dr. mount 

leave. check loc 

COMPLEXITY : Constant storaqe and execution time. 

DISMOUNT. DRAGON 



NUMBER BYTES OBJECT CODE : 744 



PARAMETERS : 
a 



LOCAL VARIABLES : 
a 



GLOBAL VARIABLES : 



CALLS : 



CALLED BY 



defnum 


he .dragon 


m2 


mv . s t a t e 


name 


o i . c 


o 1 t 


p 1 t . un i t 


p r i . d i r 


tank 


t a rge t 


wpn . t ype 


x . cur ren t 


y . cu r ren t 



h i der 


1 oc 


set .sector 




• 

• 

de f end 





COMPLEXITY : Storage requirements are constant but execution 
time is linearly dependent on the number of tanks 
in p 1 t . un i t . 
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DIST 



' NUMBER BYTES OBJECT CODE : 14« 



PARAMETERS : 
xl 
y 1 

LOCAL VARIABLES : 
d i stance 
x 2 

y2 

CALLS : 

sq r t . f 

CALLED BY : 

arty.irnpact 

commo . a 1 1 emp t 

error 

fire 

impact 

COMPLEXITY : Constant storage 

REMARKS : Returns the value 
rout i ne . 



x 2 

y2 



x 1 

yl 



assessment 

compute 

f dc . process i ng 
quns.firino 
new .location 

and execution time. 

of distance to the callina 



l a l 



DOING. CLUSTERS 



NUMBER BYTES OBJECT CODE : 5048 



PARAMETERS 



LOCAL 



WRITES 



CALLS : 



CALLED BY 



i d . f o 


name. priori ty 


P r i .value 




:ables : 




a 


ang 1 e 


b 


di r 


i 


i d . f o 


j 


' k 


1 


m 


n 


name. priori ty 


pr t .value 


s 


tank 


total .clusters 


X 


y 


IIABLES : 




a 1 i ve . dead 


b . o rg . a l i ve 


bo x . t o 1 erance 


clusters 


c. number. array 


debua 


di r.of.mvmt 


f o . max . range 


f o .mi n . range 


list 


name 


old. cluster. number 


sod 


stated 


t a raet 


x .current 


y . cu r rent 




clusters 


i 


i d . f o 




abs . f 


a rc t an . f 


cos . f 


d i m . f 


l oc 


s i n . f 


• 

• 

update. c 1 uster 





COMPLEXITY : Storage is constant but execution is deoendent 
on the product of the size of the target list and 
the total number of clusters. 



REMARKS : Returns the values of name . d r i o r i t y and 
to the calling routine. 



p r i .value 



DR. MOUNT 



•NUMBER BYTES OBJECT CODE : 1192 



PARAMETERS : 
a 

LOCAL VARIABLES : 







a 






J J i 




GLOBAL 


VARIABLES : 














ap. tow 






defnum 








f i P 






- he. drag 








m2 






m'v. state 








name 






pl t 








p 1 t . un i t 






tank 








t a rqet 






t i me . v 








t . SDd 






won . t yoe 








x. cur rent 






y. current 




CALLED 


BY 


• 

• 














bug. check 






1 eave. check 




SCHEDULES 


• 

• 














df .chq 










COMPLEXITY 


: Execution 


time 


increases linear w 


i t h numbe r 






tanks in 


o 1 t . 


uni t 


with won. type 


= 6 and 






he. drag (tank) 


gt 


0 and 


fir(tank) ne 1. 


Storage i s 



constant . 



END. OF. MISSION 



-NUMBER BYTES OBJECT CODE : 2704 



PARAMETERS : 



i d . b t r y 
i d . f o 



i d . f dc 
i d . mi s s i o n 



LOCAL VARIABLES : 

estimate. of. time 
i d . f dc 
i d . m i s s i o n 
time 



i d . bt ry 
i d . f o 
time 



GLOBAL VARIABLES : 

amt. active. msns 

b t ry 

fist 

ho 1 di ng.msns 
1 abe 1 
msn .name 
ms n . t i me 
new. location 
queue .si z e 
s t at e 1 
t i m e . v 



amt .msns . f i red 
debug 

howi t ze r . queue 
mission 

my . r ad i o 
num.adj .rounds 
queue .time 
s t . f i r i ng 
which, vo 1 ley 



WRITES : 

fist 
i d . f dc 
msn. name 



i d.bt ry 
i d. f o 
t i m e . v 



FILES : 
REMOVES 



id. mission in msn. queue 



id. mission from howitzer.aueue and holding. msns 



CALLS : 

arty . t i me 



t racer 



SCHEDULES : 

fo. not. busy quns. firing 

ooen . rad i o . net 



SCHEDULED BY : 

arty.imoact error 

COMPLEXITY : Constant execution and storage r eau i remen t s . 
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ERROR 



NUMBER BYTES OBJECT COOE : 944 



PARAMETERS : 
ans 

i d . f dc 
i d .m i ss i on 

LOCAL VARIABLES : 
an s 

i d . f dc 
i d . m i s s i on 
sig.y 
xd i f 

x. normal .error 
y . i mpact .poi nt 

GLOBAL VARIABLES : 

ammun i t i on . t ype 
error .code 
rn. stream 
x . future. 1 oc 

CALLS : 

d i s t 

norma 1 . f 
position .update 

CALLED BY : 

arty. i moac t 

SCHEDULES : 

end .o f .mission 



i d.bt ry 
i d . f o 



i d . bt ry 
i d . f o 
s i g. x 
,• tank 

x . i mpact .point 
y d i f 

. y. normal. error 



cal i De r 

gt . f i na 1 . 1 oc 

theta 

y. future. loc 

new. coordinate. system 
parameters 
t racer 



COMPLEXITY : Constant execution and storage requirements. 
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FA . 1 .MAIN 



LOCAL 



GLOBAL 



NUMBER BYTES OBJECT CODE : a936 

VARIABLES : 

i j 

It 1 

m 



VARIABLES : 

amt . ammo .types 

amt .cal ibers 

amt . f f e . vo 1 leys 

amt. red . ba 1 1 e rys 

b . num . a 1 i ve 

box . to 1 erance 

cutof f . t i me 

di sol acement 

f o .max . range 

f o . veh i c 1 e 

1 araest .num.wons 

max. number. of .mi ssions 

max. ranqe 

n. battery 

n . f o 

n . r ad i o 

num. he. left 

p.punch 

rate. of . f i re 

r.num.al ive 

r.org.al i ve 

s i gma . dp i cm 

travel .time. array 

x.cui»l 

y .curl 



amt .blue.batterys 
amt .fa. time. del tas 
am t . m r 1 

^arty.ok.table 
b.org.al ive 
co 1 o r 1 
debug 
d . r ad i us 
f o .mi n . range 
fwa.obs.msn. tolerance 

per . f o 

miss. tolerance 
n . f dc 

no . range .bands 
num . do i cm . left 
num . guns 
ranqe .bands 
red. 1 .constant 
rn. stream 
salvos 

tgt .acq. error 
t r . t i me 
x . cu r2 
y . cu r2 



FA. 1. MAIN Ccont ) 



READS : 

amt .ammo. types 
amt .cal i bers 
amt . f f e . vo 1 leys 
amt .red.batterys 
box . to 1 erance 
cutoff. time 
d i sd 1 acemen t 
f o . max . range 
f o . vehicle 
1 argest .num.wons 
max. number. of. missi 
max. range 
n .bat t ery 
n . f o 
n . r ad i o 
num.he.left 
p . punch 
rate. of. fire 
s i gma . dp i cm 
t rave 1 . t i me . array 
x .curl 



amt.blue.batterys 

amt. fa. time. del tas 

amt .mr 1 

arty.pk.table 

co 1 or l 

debug 

d. radi us 

f o . m i n . r ange 

fwd.obs.msn. tolerance 

.per . f o 

mi ss.tol erance 
n . f dc 

no . r ange .bands 
num . dp i cm . 1 e f t 
num .guns 
range .bands 
rn . stream 
tqt . acq. error 
t r . t i me 
y . c u r 1 



CREATES : 

battery fdc 

f o radio 



RESERVES 



array. detect 

clusters 

d i sol ac emen t 

fa. time. del tas 

lethal . rad i us 

red.pl anned. fi res 

time. last. cluster. update 

travel .time. array 



arty.pk.table 
c. number. array 

fo.vehcle 
range .bands 
s i gma . do i cm 
tgt .acq. error 



RELEASES : 

prepl anned 



CALLS : 

o rep 1 anned 



CALLED BY : 

main 



COMPLEXITY : Linear on n.fdc# n. battery# amt . ammo . t ypes 

am t . c a 1 i be r s # amt . b 1 ue . ba 1 1 e ry s * num. guns 

amt. calibers * no . range . bands 

IMPROVEMENTS : Reads num. dpicm. left then sets to 0. 



FA. 2. MAIN 



LOCAL 



GLOBAL 



WRITES 



NUMBER BYTES OBJECT COOE : 3472 

VARIABLES : 

i j 

k 1 



VARIABLES : 

amt . ammo .tyoes 

am t . c a 1 i be r s 

amt.ffe.vol leys 

amt . red .bat t erys 

b.org.al ive 

cutof f . t i me 

d . rad i us 

f o .max . range 

f o . vehicle 

largest .num.wons 

max. number. of. missions 

mi ss . t o 1 e ranee 

n . f dc 

no . range .bands 
n . tanks 
po i n t i ng . t o 
rn . st ream 
r r roo i nt 



amt . ammo . t yoes 
amt .cal i bers 
amt.ffe.vol leys 
amt .red . ba t t e ry s 
box .tol erance 
debug 

f o .max . range 
fwd.obs.msn. tolerance 
max. number. of. missions 
mi ss . tol erance 
n . f dc 

no . range . bands 
n . t an ks 
r .org .a 1 ive 



amt. blue. batterys 

amt. fa. time. del tas 

amt . m r 1 

arty. pk. table 

box. tolerance 

debug 

f a 

f o . min. range 
fwd.obs.msn. tolerance 
lethal . radi us 
per. fo 

n. battery 
n . f o 
n . r ad i o 
p i . c 
p .punch 
r . o rg . a 1 ive 
type 



amt. blue. batterys 
amt. fa. time. del tas 
am t . m r 1 
b.org.al ive 
cutoff. t i me 
d . rad i us 
f o .mi n . range 
1 argest .num.wons 
pe r . f o 

n .bat tery 
n . f o 
n . r ad i o 
p .punch 
rn. stream 



FA. 2. MAIN (cont) 



CALLS : 

sort . f 

CALLED BY : 

main 



SCHEDULES : 

red .arty.fi res 


update .cluster 



COMPLEXITY : Linear on n.fo* amt. calibers * amt . ammo . t yoes * 
9, amt.red.batterys - a'mt.mrl 

IMPROVEMENTS : Combine major looDS. 

FA. TGT. ERROR 



NUMBER BYTES 


OBJECT CODE : ai6 


PARAMETERS : 
a 


1 oc . e r r o r 


LOCAL VARIABLES : 
a 


loc. error 


GLOBAL VARIABLES : 
rn. stream 


tgt .acq. error 


CALLS : 

t racer 

CALLED BY : 

new. location 


uni f o rm . f 



COMPLEXITY : Constant execution and storage requirements. 

REMARKS : This routine returns the value of loc. error to the 
calling routine. 



FOC. PROCESSING. 



NUMBER BYTES OBJECT CODE : 3424 



PARAMETERS : 

i d . f o 



i d . m i ss i on 



LOCAL VARIABLES : 
di f f 
i d . b t ry 
i d . m i s s i o n 
k 
m 

time 
vo 1 leys 
yy 



i 

i d . f o 

j 

1 

rg 

t ype . ammo 

x X 



GLOBAL VARIABLES : 

ammun i t i on . t yoe 
amt . f f e . vo 1 1 eys 
debug 

error .code 

gt . final. rg 

mission 

msn . name 

msn . t i me 

n.holding.msns 

process 

start 

status 

t i me . v 

volleys. to. fire 
x . cur 4 
y . cur 1 

y . future . 1 oc 



amt .act i ve.msns 

busy 

do i cm 

fwd.obs.msn.tol erance 
gt .initial. rg 
my . rad i o 

n . f dc 

num.mi ssions 
queue .size 
st at e 1 
theta 

x . cu r 1 

x . future. 1 oc 
y .cur4 



WRITES : 



FILES : 



i 

msn .name 
queue ♦ s i ze 
time.v 



i d . f o 

num .mi ssions 
s t a t e 1 



id. mission in holding. msns and msn. queue 



CALLS : 

a r t y . t i me 
t racer 



a rc t an . f 
di st 
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FDC. PROCESSING Ccont) 



SCHEDULES : 

checking. guns. avai 1 ibi 1 i t y 
f o .not .busy 

SCHEDULED BY : 

commo . at t emot 

COMPLEXITY : Execution time is linear with n.fdc and storage 
is constant. 

IMPROVEMENTS : Combine all "for" loops into one. 
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FINAL. DEATH 



.NUMBER BYTES OBJECT CODE : 142a 



PARAMETERS : 
a 

LOCAL VARIABLES : 
a 

GLOBAL VARIABLES : 

a 1 i ve .dead 
f . d 
f k i 1 1 
hit. state 
kki 1 1 
m f k l 1 1 
name 
num . h i t 
t i me . v 

x . current 
2 .cur ren t 

WRITES : 

de f num 
f i red . a t 
guntube 
k . h i t 
m . d 
m k i 1 1 
ncase 
sod 

won . t yoe 

y . current 

CALLS : 

tally. hit. state 

SCHEDULED BY : 
a t r i t 

COMPLEXITY : Constant 

requ i regents. 



de f num 
f i red . at 
' guntube 
k . h i t 
m . d 
mk i 1 1 
ncase 
sod 

won .type 
y. current 



f ,d 
f ki 1 1 

hit. state 
kki 1 1 
m f k i 1 1 
name 
num . h i t 
t i me . v 
x. current 
z. current 



execution time and 



storage 
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FIRE 



NUMBER 

PARAMETERS : 
a 

LOCAL VARIABLES : 
a 

lose 

stoo . count 

GLOBAL VARIABLES : 

a 1 i ve .dead 
bwd .look 
color 
de f num 
f i o 

f wd .look 
mz 1 . ve 1 
pc t . v i s 
P r o j o 
sc hed 
tgt . sc 1 
won .type 
y .current 

CALLS : 

decrement .ammo 
h i d e r 

set . muz z 1 e.vel 

stop. to.fi re 

SCHEDULES : 

i mpac t 

SCHEDULED BY : 

t72. tactics 
we .m i s s 

COMPLEXITY : Constant 

requ i remen t s . 



BYTES OBJECT CODE : 2232 



i d 



id 

r 



/-blue 

c hec k . t i me 
critical .value 
foe 
f ki 1 1 
mv. state 
op . r ng 
pointer 
range 

second . shot 
t i me . v 
x. current 



d i st 
1 oc 
sight 
t racer 



target .select 



target .select 



execution time and 



storage 
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FIRST 



NUMBER BYTES OBJECT COOE : 288 

PARAMETERS : 
a 

LOCAL VARIABLES : 



GLOBAL VARIABLES : 

mu . ranpe 

wpn. type ' 

CALLS : 

t rune . f 



CALLED BY : 

1 ay . 1 oad 



COMPLEXITY : Constant 

r equ i remen t s . 


execution time 


and 


storage 




FO. NOT .BUSY 






NUMBER 


BYTES OBJECT CODE 


: a 08 




PARAMETERS : 

i d . f o 








LOCAL VARIABLES : 
i d . f o 

GLOBAL VARIABLES : 

amt . ac t i ve . msns 
status 


idle 






SCHEDULES : 

uoda t e . cluster 








SCHEDULED BY : 

end. of. mi ssion 


fdc .process i ng 




COMPLEXITY : Constant 

requ i r emen t s . 


execution time 


and 


s t o rage 
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GEOM 



•NUMBER BYTES OBJECT COOE : 



PARAMETERS : 

adde f 1 
de f 1 b i as 
e 1 b i as 
f .pcv i s 
r 

tgt . t 

LOCAL VARIABLES : 
adde f 1 
a i md i s 
de f 1 b i as 
de f 1 s i g 
e f k i 1 1 
e 1 b i as 
el mi s 
e 1 s i g 
emp 1 
f k 
i 
j 

k 

kayp 1 
1 

m 

mo 

n 

r 

s h . t 
tat ."t 
ve 1 
width 
y . t 

GLOBAL VARIABLES : 

a 1 i ve . aead 
di r.of.mvmt 
jnorm 
1 el 1 
1 e3 1 
1 e 7 1 
1 e81 
norseed 
projo 
t ardi m 
wpn . type 
y .current 



adde 1 
de f 1 s i g 
e 1 s i g 
pc . v i s 
sh . t 



adde 1 
de f d i s 
de f 1 m i s s 
d i sw k 
e f p 1 
e 1 d i s 
e 1 m i s s 
emk i 1 1 
f .pc v i s 
gamma 
i o 
j o 

kay k i 1 1 
kk 

1 enqt h 
m k 
mp 

pc . v i s 
ro 

size 
t u r ret 
whoc a 1 led 
x . t 



damage . num 
h no rm 
kki 1 1 
1 el2 
1 e6 1 
1 e72 
1 e8 3 
oh 
sod 

veh . t yoe 
x. current 



8080 



155 



GEOM (con t ) 



CALLS : 



abs . f 
a t r i t 
1 oadn 
t rune . f 



CALLED BY : 

comou t e 



arctan, f 
cos . f 
s i n . f 



COMPLEXITY : Constant execution time and 

r equ i remen t s . ’ 



GET. UP 

NUMBER BYTES OBJECT CODE : 576 



PARAMETERS : 

a b 

LOCAL VARIABLES : 

a o 



GLOBAL VARIABLES : 





ao.tow 


bn 




de f num 


mv. state 




name 


red . a 1 i ve 




tank 

wpn . t yoe 


target 


CALLS : 


1 oc „ 




CALLED BY 


• 

• 

charge 




complexity 


: Cons t an t 

requ i remen t s . 


execution time and 



storage 



storage 
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GUNS. FIRING 



NUMBER BYTES OBJECT CODE : I7t>8 



PARAMETERS : 

i d . bt ry 
i d . f o 

LOCAL VARIABLES : 
i d . b t r y 
i d . f o 

rg . 

t y pe . ammo 



GLOBAL VARIABLES : 





ad j .round 
cal i b e r 
gt . final .rg 
my . rad i o 
t ime.v 

which, vo 1 ley 
x . c u r 1 
y . cu r 1 


WRITES : 


i d . b t r y 
i d . f o 
t i me . v 


CALLS : 


di st 


SCHEDULES 


• 

• 

a r t y . i moac t 
ooen . radi o .net 


SCHEDULED 


BY : 

ar t y . i moac t 
c hec k i ng . guns . 
end. of. mi ssion 



COMPLEXITY : Constant 

requ i remen t s . 



i d . f dc 
i d . m i s s i o n 



i d . f dc 
i d . m i s s i o n 
t o f 

won .type 

ammuni tion.tyoe 

debug 

msn.name 

now.fi r i n q 

travel .time. array 

x. future. loc 
y . future . 1 oc 



i d . f dc 

msn .name 

wh i ch . vo 1 ley 



t r ac e r 



busy.radio.net 



i 1 ab i 1 i t y 



execution time and 



storage 
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HIDE 



NUMBER BYTES OBJECT CODE : 1536 

PARAMETERS : 





a 


whocal led 


LOCAL VARIABLES : 






a 

whocal 1 ed 


hold 


GLOBAL VAR 


IABLES : 






a 1 i ve .dead 
mv. state 


defnum 


CALLS : 




h i der 


re 1 oad 


SCHEDULES 


• 

• 

hide 




SCHEDULED 


BY : 






h i de 


reload 




we • h i t 


we • m i s s 



COMPLEXITY : Constant storage and execution time. 

HIDER 

NUMBER BYTES OBJECT CODE : 320 



PARAMETERS : 
a 



LOCAL VARIABLES : 




a 


ade f 


aname 


w t ype 


GLOBAL VARIABLES : 




de f num 


micro 


name 

zh 


won . t ype 


CALLS : 




mcov 




CALLED BY : 




b 1 .create 


defend 


d f . c hg 


d i s m o u n t 


fire 


h i de 


red. create 


t a rget . 


we . h i t 


we . m i s s 



COMPLEXITY : Constant storage and execution time. 
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IFV. TACTICS 



• NUMBER BYTES OBJECT CODE : 352 

PARAMETERS : 

a b 

LOCAL VARIABLES : 
a 
b 

GLOBAL VARIABLES : 
foe 

p 1 t . un i t 

CALLS : 

uni f orm . f 

CALLED BY : 

target .sel ect 

COMPLEXITY : Execution is linear on tank in pit. unit 
storage is constant. 



o 1 t 
tank 



answer 

z 



and 
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IMPACT 



NUMBER BYTES OBJECT CODE : 



PARAMETERS : 
a 

y 

LOCAL VARIABLES : 
a 

dt 

r 

whoca 1 l ed 
y 

GLOBAL VARIABLES : 

a 1 i ve .dead 
check .time 
critical .value 
dam. array 
f a 

f i red .at 
f k i 11 
f wa . 1 ook 
gunt ube 
k . h i t 
kk i l 1 
m f k i 1 1 
mmm 
name 

num . h i t 

pc t , v i s 
pro j p 

SDd 

tow . kount 
wpn . t y pe 
y .current 



WRITES : 

def num 
f i red. at 
q • d in ni 
hi testate 
k k i 11 
m f k i 1 1 
name 
num . h i t 
P r o j o 
sod 
1 1 1 

x . cu rrent 
z .current 



i d 



answer 
i d 

s topcount 

x 

/ 



b wd . 1 ook 
co 

damage .num 
de f num 
f .d 
f l P 
foe 
g • a m m 
hit. state 
killer 
m . d 
mk i l 1 
mv. state 
nc ase 
pcb . v i s 
pointer 
range 
t i me . v 
1 1 1 

x .cur rent 
z .current 



f . d 
f ki 1 1 
gunt ube 
k . h i t 
m . d 
mk i 1 1 
ncase 
pcb . v i s 
range 
t i me . v 
wpn. type 
y .cur rent 



4488 
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IMPACT (cont) 



CALLS 



bug. check 
d i s t 
1 oc 
sight 

tally. hit. state 
we . h i t 



compute 



we . m i s s 



list .updat e 
sec tor. check 
stop.to.fi re 
t racer 



SCHEDULES : 

detect mrl .impact 

new . f o 

/ 

SCHEDULED BY : 
fire 

COMPLEXITY : Constant execution time and storage 

requ i rement s . 
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ITV. TACTICS 



NUMBER BYTES OBJECT CODE : 352 



PARAMETERS : 
a 



b 



LOCAL VARIABLES 
a 
b 



answer 

z 



GLOBAL VARIABLES : 

foe ' o 1 t 

pit. unit tank 



CALLS : 

uni form.f 



COMPLEXITY : Execution time linear on tanks in olt. 
storage is constant. 



CALLED BY : 

t a rget .select 

REMARKS : Returns the 

routine. 



va 1 ue o f answe r 
LAY. LOAD 



to the 



NUMBER BYTES OBJECT CODE : 2136 



PARAMETERS : 

a x 

LOCAL VARIABLES : 

a time 

x 

GLOBAL VARIABLES : 

p ro j o wpn .type 

CALLS : 

first max.f 

normal . f 

CALLED BY : 

t72. tactics t a rge t . se 1 ec t 

we.mi ss 

COMPLEXITY : Constant execution time and 

requ i remen t s . 

REMARKS : Returns the value of time to the calling 



unit and 



cal 1 i nq 



s t orage 
rout i ne. 
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LEAVE. CHECK 



NUMBER BYTES OBJECT CODE : 9768 



PARAMETERS : 
a 

LOCAL VARIABLES : 
a 

bb 
cb 
i j 

i m 

GLOBAL VARIABLES : 
ap . tow 
bn 

color 
de fnum 
hasty 
m v . state 
pl t 
red 
tank 
t .dead 
t . sod 
won . t ype 



CALLS : 

dr .mount 
t rune . f 

CALLED BY : 

tally. hit. state 

SCHEDULES : 

charge 



b 

be 
cc 
i k 



blue 

co 

comp. uni t 
f a 
m2 

name 

o 1 t . un i t 
r ed . a 1 i ve 
t a rge t 
t i me . v 
upper .lower 



1 oc 



df .chg 



COMPLEXITY : Execution time depends on tanks in como.unit * 
tanks in pit. unit and storaae is constant. 
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LIST. UPDATE 



NUMBER BYTES OBJECT CODE : 1840 

PARAMETERS : 

a b 

lose whoca 11 ed 



LOCAL VARIABLES : 





a 


b 




count 


f 1 ag 




i 


lose 




s i ze 


Hhoc a l led 


GLOBAL VARIABLES : 






a 1 i ve . dead 


f a 




list 


t emo . t gt 


RESERVES 


# 

• 

list 




RELEASES 


• 

• 

list 




CALLS : 




d i m . f 
uni form.f 


m i n . f 


CALLED 8 Y 


• 

• 






detect 


i moac t 




Droximity. detect 


t a rge t . se 



SCHEDULES : 

t a rget .select 

COMPLEXITY : Execution time and storage are linear 

e 1 emen t s in list. 
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on 



LOC 



NUMBER BYTES OBJECT CODE : 1096 



PARAMETERS : 

tank 

LOCAL VARIABLES : 
tank 

GLOBAL VARIABLES : 



alive .dead 


blue 


CO 


<;o 1 o r 


de f num 


list 


m k i 1 1 


m . red . 


mv. state 


name 


pi t 


red 


spd 


target 


wpn .type 





REMOVES : 

tank from red. alive* comp. unit and pit. uni 

RELEASES : 

list 

CALLS : 

convert .back 
pa r am . se t 

CALLED BY : 

assessment 
detect 

doing. clusters 
get .uo 
1 eave .check 
m r 1 .impact 
red. arty.fi res 
t72. tactics 

SCHEDULES : 

df .chq 

COMPLEXITY : Constant execution time and 

requ i rement s . 



defend 



commo .pass. tat 
di smount.draaon 
fire 
impact 
1 oc . upda t e 
oos i t i on .update 
st op. simulation 
target .select 



s t o r age 
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LOC. UPDATE 



' NUMBER BYTES OBJECT CODE : 384 

LOCAL VARIABLES : 
tank 

GLOBAL VARIABLES : 

alive. dead delta. t 

CALLS : 

1 oc 

SCHEDULES : 

1 oc . uodat e 

SCHEDULED BY : 

loc. update red. create 

COMPLEXITY : Constant execution time and 

requ i remen t s . 



s t o rage 
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MAIN 



NUMBER BYTES OBJECT CODE : 5928 



LOCAL VARIABLES : 

cnum i 

j pnum 



GLOBAL VARIABLES : 
area 

be . coun t 
b . pc t . at t 
case 
cdt i me 
constant 
d . num 
de f . t i me 
ds 1 

guntube 
i . dead 
j n o r m 
1 ines.v 
mmm 
nc ase 
nnn 

n .pi atoon . 1 eader 
pca.vi s 
peb . v i s 

p 1 atoon .leader 
p . v 

r . a rea 
r.num.al ive 
seed . v 
s 2 . 1 1 m e 
target 
temp . tgt 
1 1 1 
v . ms 
x . c t 
y . Ct 
z .ct 



b . area 
b . num . a 1 ive 
bt t i me 
c .bar 

company. commanoer 

critical. value 

dam . a r r ay 

de 1 t a . t 

ds2 

hasty 

i t .dead 

1 i n 

m . de t 
mu 

n. company. commander 
no r seed 

oc a . unc 
Deb . unc 
p . hat 
p 1 . c 
qa 

rc .coun t 
r .pc t . at t 
s 1 . t i me 
steps 
t . dead 
t gt sc l 

upper .lower 

w . k .c 

x. stoo 

y . s t op 
zh 



READS : 

b.num.al ive 

cnum 

ds 1 

guntube 

ncase 

r.num.al ive 
seed . v 
x . stop 



b.oct.att 
del t a . t 
ds2 
mu 

onum 

r .oct .att 
upper . 1 owe r 
y . s t oo 
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MAIN (cont) 



WRITES : 

b .dc t .at t 
norseed 
upper . lower 
y . s t op 



CREATES : 


every platoon. leader 


every company .commander 


RESERVES 


• 

« 






bbboo i n t 


c .bar 




dam. array 


'd . n u m 




ds 1 


ds2 




i .dead 


i t .dead 




m . det 


mu 




pc a . unc 


oc a . v i s 




pcb . unc 


pcb . v i s 




p.hat 


P 1 .c 




P.v 


QQ 




r r roo i n t 


t a rge t 




t .dead 


t emD . t qt 




tgt sc 1 


v . ms 




X .c t 


y . c t 




4-J 

o 

• 

N 


zh 


RELEASES 


• 

• 






fa. 1. main 


fa. 2. main 




rest 


re s2 




re s 3 
res5 


res A 


CALLS : 


** 






bl .create 


cos . f 




fa. 1. main 


fa. 2. main 




i n i t rd 


1 oadn 




rest 


res2 




res 3 


r e s A 




res5 

va 1 s . for. case 


set .sector 



gun t ube 
r.pct .att 
x . s t op 



SCHEDULES : 

at t r i t i on .check new. forces 

step. time s t op . s i mu 1 a t i on 

s t op . s i mu 1 at i on 

COMPLEXITY : Execution is dependent on the number of tanks. 

Storage is deoendent on the number of platoon 
leaders* the number of company commanders ana the 
number of elements in r.num. alive and b.num.alive. 

REMARKS : Main routine starts the simulation. 
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MRL. IMPACT 



NUMBER BYTES OBJECT CODE : 25o8 



PARAMETERS : 

X . 1 oc 

LOCAL VARIABLES : 

i d .bt ry 
no .mens . f i red 
red. 2. constant 
x 

y . 1 oc 

GLOBAL VARIABLES : 

a 1 i ve . dead 
cal i be r 
de f num 
f i red .at 
foe 

hit. state 
k . h i t 
m . d 
mk i 1 1 
ncase 

num . he . 1 e f t 
red. 1 .constant 
tank 

wpn . type 
y. current 



WRITES : 

cal i be r 
f.d - 
f ki 1 1 

hit. state 
kki 1 I 
m f k i 1 1 
name 
num .hit 
t i me . v 
x .cur rent 
z . cu r ren t 



CALLS : 

abs . f 
1 oc 

uni forra.f 

SCHEDULED BY : 

i moac t 



y . 1 oc 



i d . red .bt ry 
ok 

t yoe . ammo 
x . 1 oc 



arty. pk. table 

debuq 

f.d 

f ki 1 1 

auntube 

k k i 1 1 
m f k i 1 1 
name 

no.msns.fi red 

num .hit 

sod 

t i me . v 
x .current 
z .cur rent 



de f num 
f i red . a t 
gunt ube 
k . h i t 
m . d 
m k i 1 1 
ncase 
sod 

type .ammo 
y. current 



a t r i t 
tracer 
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MRL. IMPACT (cont) 



COMPLEXITY : Execution time is linear on tanks in blue. alive 
and storage is constant. 



REMARKS : Local variable no . mens . f i red should be 

no.msns.fi red. 

NEW. COORDINATE. SYSTEM 



NUMBER BYTES OBJECT CODE : 88 



PARAMETERS : 

ang 1 e 
yo 1 d 

LOCAL VARIABLES : 
ang 1 e 
xo 1 d 
yo 1 d 

CALLS : 

cos . f 
t racer 

CALLED BY : 

assessment 



xo 1 d 



x new 
y new 



s i n . f 



error 



COMPLEXITY : Constant execution time and storage 

r equ i rement s . 

REMARKS : Yielding xnew and ynew 



NEw.FO 

NUMBER BYTES OBJECT CODE : U56 



PARAMETERS : 
a 

LOCAL VARIABLES : 

b 1 ue . a 1 i ve 
fa 

tank 

SCHEDULED BY : 

i mpac t 



co 

o 1 t . 1 dr 
type 



COMPLEXITY : Execution time is linear on tank in blue. alive 
with co(tank) = co(a)» until tank = p 1 t 1 d r ( t an k ) . 
Storage requirements are constant. 
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NEW. FORCES 



NUMBER BYTES OBJECT CODE : 128 

PARAMETERS : 

start stoo 

LOCAL VARIABLES : 

start stoo 

GLOBAL VARIABLES : 
name 

RELEASES : 

bbbpoint red. create 

rrrpo i nt 

CALLS : 

red .create 

SCHEDULED BY : 
main 

COMPLEXITY : Constant execution time and 

regu i regents. 



storage 
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NEW. LOCATION 



NUMBER BYTES OBJECT CODE : 138a 



PARAMETERS : 





a 

i d . m i s s i o n 


del .time 


LOCAL 


VARIABLES : 






a 


del .time 




distance 


err. 1 




e r r . 2 


e r r . 3 




err .a 


err.5 




e r r . 6 


er r . 7 




e r r . 8 


i d.bt ry 




i d . f dc 


i d . f o 




i d . m i s s i on 


tank 




x . 1 


x . 2 




x . 3 


X X 


GLOBAL 


VARIABLES : 






di r.aDparent 


direction 




error .code 


mission 




sod . aDoa rent 


t yoe 




x .cura 


x.future.loc 




y .cura 


y . future. 1 oc 


CALLS 


• 

m 






arctan. f 


cos . f 




di st 


fa. tat .error 




oos i t i on .update 
t race r 


s i n . f 


CALLED 


BY : 






arty, i moact 


update. cluster 


COMPLEXITY : Constant 

requ i remen t s . 


execution time and 



storage 



NEW. MISSION 



NUMBER BYTES OBJECT CODE : 1432 



PARAMETERS : 

i d . f o 

name .pr i o r i t y 

LOCAL VARIABLES : 
a 
m 

pr i or i t y 

GLOBAL VARIABLES : 

amt.in.clusters 
direction 
f o . t gt . range 
mission 
no. clusters 
pri .of. cluster 
t i me .of . upda t e 
x.curU 

WRITES : 

a 

i d . f o 
soeed 
y .cur4 

CREATES : 

mission 

CALLS : 

di st 

CALLED BY : 

uodat e. cluster 

COMPLEXITY : Constant 

requ i renent s . 



m 

0 r i o r i t y 

1 d . f o 

name . p r i o r i t y 



c 1 usters 
fist 
1 c ount 
msn .name 
po i nt i ng. to 
speed 
t i me . v 
y . c u r 4 

direction 
msn . name 
x .cur4 



t race r 



execution time and 



\ 



s t o r age 
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OPEN. RADIO 



NET 



NUMBER BYTES OBJECT CODE 



240 



PARAMETERS : 

i d . r a d i o 

LOCAL VARIABLES : 
i d . r a d i o 

GLOBAL VARIABLES : 
st at e3 

CALLS : 

t race r 

SCHEDULED BY : 

arty. impact commo . a t t emo t 

end . o f *m i ss i on guns.firinq 

COMPLEXITY : Constant execution time and 

requ i rement s . 



storage 
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PARAM. SET 



• NUMBER BYTES OBJECT CODE : 920 



PARAMETERS : 
a 



LOCAL VARIABLES : 
a 

weaoon ry 



aname 



GL08AL VARIABLES : 



c • ba r 


c b a r 


def num 


di r .mvmt 


d • num 


m .det 


micro 


mine.det 


mv • t i me 


name 


p • hat 


pi .hat 


P 1 .c 


plow, cond 


P. V 


sod 


t i me . v 


t . spd 


v . ms 


won.tyoe 


x.ct 


x .current 


y . c t 


y. current 


z . c t 


z . cu r ren t 



zh 

CALLS : 

move 



CALLED BY : 

1 oc 

COMPLEXITY : storage reaui rements and execution time 
constant . 



are 
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PARAMETERS 



NUMBER BYTES OBJECT CODE : 1128 



PARAMETERS : 



j 


k 




rg 


t ype . ammo 




LOCAL VARIABLES : 


count 


de 1 t a . 1 




del t a . 2 


fraction 

j 

pg 




1 

k 




s i g . d f 


s i g . rg 




GLOBAL VARIABLES : 


no • range .bands 


r ange .bands 




CALLS : 

tracer 
CALLED BY : 


assessment 


error 




COMPLEXITY : execution 


time is linear depending on 


the 


number of range bands. Storage is constant. 




REMARKS : This routine 


returns the value of sig.rg 


and 


sig.df to the 


calling rout i ne . 
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POP. A. MINE 



NUMBER BYTES OBJECT COOE : 1 76 0 



PARAMETERS 





tnk 


type 


LOCAL 


VARIABLES : 






e f k i 11 


e m k i 1 1 




j o 


k a y k i 1 1 




t n k 

whoc a 1 led 


t ype 


GLOBAL 


VARIABLES : 


/ 




damage . num 


dam. array 




de f num 


f . d 




f i red . at 


f k i 11 




gun t ube 


hit.state 




k . H i t 


k k i 1 1 




m ,d 

m i n 1 e t h 


m f k i 1 1 




mk i 1 1 


name 




ncase 
pi ow.cond 


num • h i t 




sod 


t i me • v 




won .type 


x .cur rent 




y. current 


z .cur rent 


WRITES 


• 

• 






de f num 


f .d 




f i red .at 


fkill 




gunt ube 


hit.state 




k . h i t 


k k i 1 1 




m . d 


m f k i 1 1 




mk i 1 1 


name 




ncase 


num .hit 




sod 


t i me • v 




wpn .type 


x .cur rent 




y .current 


z .cur rent 


CALLS 


• 

• 

at r i t 




CALLED 


BY : 

convert .back 




COMPLEXITY : Storage requirements 


and execi 



t i me 



constant 



are 
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POSITION. UPDATE 



•NUMBER BYTES OBJECT CODE : 1104 



PARAMETERS : 
a 



i d . m i ssion 



LOCAL VARIABLES : 
a 

i d . m i ssion 
tank 
y .bar 



i d . f o 
spd .ba r 

x . ba r 



GLOBAL VARIABLES : 



CALLS : 



CALLED BY 



b . o rg . a 1 i ve 


C .number .array 


direction 


fist 


name 


no. clusters 


red . alive 


spd 


speed 


stated 


t i me . v 


t . pos i t i on 


x. current 


x . cu r 4 


y .current 


y . cu r4 



Cos . f 


1 oc 


s i n . f 


t racer 


# 

• 

a r t y . i mpac t 


error 


new .location 





COMPLEXITY : Storage reauirements are constant. Execution is 
linear on tanks in red. alive. 



1 78 



PREPLANNED 



NUMBER 

PARAMETERS : 
a 
c 
e 

LOCAL VARIABLES : 
a 
c 
e 
i 
k 

GLOBAL VARIABLES : 

red .planned. fir 

CALLED BY : 

f a . 1 .main 

COMPLEXITY : Constant 

requ i rement s . 



BYTES OBJECT CODE : 1008 



b 

d 

f 



b 

d 

f 

i 

1 



s 



execution time and 



PRINT 

NUMBER BYTES OBJECT CODE : 336 



storage 



PARAMETERS: 

i d .m i ss i on 

LOCAL VARIABLES : 

debiig i d . m i ss i on 

rad. err x . cu r 4 

x. future. 1 oc y.cur4 

y . future. 1 oc 

WRITES : 

rad . e r r 

CALLS : 

di st 

CALLED BY : 

a r t y . i moac t 

COMPLEXITY : Constant 

requ i rement s . 



assessment 

execution time and storage 
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PRINT1 



NUMBER BYTES OBJECT COOE : 1124 



PARAMETERS : 

i d . m i ss i on 

LOCAL VARIABLES : 
i 

i d . m i s s i on 
tank 

GLOBAL VARIABLES : 

b . o rg . a 1 i ve 

debug 

name 

rd. offset 
red . a 1 i ve 
tank 

x . current 

y . cur4 

y . future . 1 oc 

WRITES : 

i 

name 
x .cur 4 

x . future . 1 oc 

y . current 

CALLED BY : 

arty. i moac t 



i d. f o 

j 



e . number .array 
fist 

no.c 1 uster 

stated 
x . cur 4 

x. future. loc 

y . cur rent 



j 

rd. offset 

x . cur rent 
y . c u r 4 

y. future. loc 



assessment 



COMPLEXITY : Execution time is linear on tank in red. alive 
and storage is constant. 
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PRIORI TY. AND. ROUND. SELECT 



NUMBER BYTES OBJECT CODE : 1336 



PARAMETERS : 



a 

LOCAL VARIABLES : 
a 
D 

j 

rnd 

GLOBAL VARIABLES : 
b 1 ue 
ds 1 

won . t ype 

CALLS : 

ammo . c h ec V 

CALLED BY : 

t a rge t .select 

COMPLEXITY : Constant 

requ i remen t s . 



answer 

i 

p 

t h resho 1 d 

/ 

color 

range 



t rune . f 



execution time and 



REMARKS : Returns the value of o and rnd to the 
routine. 



storage 
cal 1 i no 
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PROXIMITY .DETECT 



. NUMBER BYTES OBJECT CODE : 864 



PARAMETERS 



a 



b 



LOCAL VARIABLES : 



a 

whoca 1 lea 
y . same 1 e 



b 

x . samp 1 e 



GLOBAL VARIABLES : 

alive .bead 
color 



blue 
p 1 t 
tank 



pi t .uni t 
x .current 



y .current 



CALLS : 

abs.f list. update 

CALLED BY : 

detect 

COMPLEXITY : Execution time is linear on tank in pit. unit 
and storaoe is constant. 
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RED. CREATE . 



NUMBER BYTES OBJECT CODE : 2408 

PARAMETERS : 

a b 

LOCAL VARIABLES : 



GLOBAL VARIABLES : 





ao.tow 


array. detect 




bbbpo i nt 


be .count 




bn 


b.num.al ive 




c . numbe r.arrav 


CO 




cocdr 


def num 




d i r . o f . mvm t 


list 




max. number. of. 


fni ssions.oer.fo 




mv . state 


name 




n . f o 


op . rng 




pi .c 


pi ow.cond 




prt 


d 1 t 1 dr 




pointer 


d r i . d i r 




sod 


tank 




t a rget 


t i me . v 




wDn.tvpe 
y .current 


x . cu r ren t 


READS : 








bn 


CO 




cocdr 


name 




pit 


o 1 t 1 d r 


CREATES : 


won . t ype 
y .current 

tank 


x .current 


FILES : 




tank in tanksr 


red. alive* comp. unit and pit. unit 


RESERVES 


• 

• 






array .detect 
list 


c .number .array 
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RED. CREATE (cont) 



RELEASES 


• 

• 






array. detect 


c .number . a r ray 


CALLS : 




b a s i c . 1 o a d 
set .sector 


h i der 


CALLED BY 


• 

• 

new .forces 




SCHEDULES 


• 

• 

1 oc . uDdat e 


/ 



COMPLEXITY : Execution is dependent on input parameters a 
and br main loop will be executed b-a+1 times per 
invocation. Storage is dependent on be. counts 
n.fo and ma x . numbe r . o f . m i s s i ons . pe r . f o . 



RED. ARTY. FIRES 



NUMBER BYTES OBJECT CODE : 3368 



PARAMETERS : 

i d. red. bt ry 



iteration 



LOCAL VARIABLES : 
i 

iteration 

red. 2. constant 

x 



id.red.btry 

Dk 

t ype .ammo 



GLOBAL VARIABLES : 

alive .dead 
b 1 ue . a 1 ive 
de f num • 
f i red . at 
foe 

hi t .state 
k k i 1 1 
m . d 
mk i 1 1 
ncase 

no .msns . f i red 
num . guns 
n u m . h i t 

red.p 1 anned . f i 

sal vos 

tank 

won .type 
y. current 



arty. pk . table 

cal i b e r 

f .d 

f k i 1 1 

gun t ube 

k . h i t 

koun t 

mf ki 1 1 

name 

num . dp i cm . left 
num. he. left 

res rn . st ream 

spd 

t i me . v 
x .current 
z. current 



WRITES : 



cal i b e r 


de f num 


f .d 


f i red .at 


f k i 1 1 


qun t ube 


h i t . st at e 


k . h i t 


kki 1 1 


m . d 


m f k i 1 1 


m k i 1 1 


name 


ncase 


num . h i t 


spd 


t i me . v 


t yoe . ammo 


x .cur rent 
z .cur rent 


y .cur ren t 
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RED. ARTY. FIRES (cont) 



CALLS : 

SCHEDULES 

SCHEDULED 

complexity 



at p i t 1 oc 

tracer uni form. f 



red.arty.fi res 
BY : 

fa. 2. main red . a r t y . f i r es 

: Storage requirement is constant. Execution time 
is dependent on the product of salvos and tanks in 
b 1 ue . a 1 i ve . 
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RELOAD 



NUMBER BYTES OBJECT CODE : 2736 

PARAMETERS : 
a 

LOCAL VARIABLES : 
a 



GLOBAL VARIABLES : 
b t i me 
c . 2 
case 
cdh 
cheat 
de f num 
guntube 
p . con 
s2 . t i me 

CALLED BY : 

h i de 

SCHEDULES : 

hide 


c . 1 
capds 
cda 
cdt i me 
erf 

de f . t i me 
i n i t 
s l . t i me 
veh.tyoe 


COMPLEXITY : Constant 

requ i rement s . 


execution time and storage 



RES 1 



NUMBER 


BYTES OBJECT CODE : 232 


GLOBAL VARIABLES : 
hnorm 

READS : 

no rseed 


no rseed 


RESERVES : 

hno rm 

CALLED BY : 

main 


norseed 


COMPLEXITY : Constant 

r ecu i rement s . 


execution time and storage 
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RES2 



NUMBER BYTES OBJECT CODE : 2000 



GLOBAL VARIABLES : 



RESERVES 



CALLED BY 



accbm 


acc h t 


acc k e 


accms 1 


addon 


bm . mov 


bushbmp 


dgn v 


h t . mov 


ke . mov 


lei 1 


1 el2 


1 e31 


1 e6 1 


1 e71 


1 e72 


!e81 


A e82 


m i n 1 e t h 


so vmg 


t a rd i m 


usmg 



accbm 


acch t 


acc ke 


accms 1 


addon 


bm .mov 


bushbmp 


dgn v 


h t .mov 


k e . mov 


1 el 1 


1 el2 


1 e 3 1 


1 e6 1 


1 e7 1 


1 e72 


1 e 81 


1 e8 3 


m i n 1 e t h 


so vmg 


t a r d i m 


usmg 


• 

• 

ma i n 





COMPLEXITY > Constant execution time and storage 
requ i remen t s . 

REMARKS : Rearrangement of subscripts will provide more 
efficient storage utilizing fewer pointers. 
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RES3 



MUMBER BYTES OBJECT CODE : 3336 



LOCAL 


VARIABLES : 






i 


j 




k 


i 




m 




GLOBAL 


VARIABLES : 






Jell 


1 el2 




1 e3 1 


1 e6 1 




1 e7 1 


1 e72 




1 e8 1 


.1 e83 


CALLED 


BY : 






main 




COMPLEXITY : Constant 


execut ion 




requ i remen t s . 





REMARKS : Rearranging loops to avoid duplication 
the number of "for" looos from 11 to 6. 

RESa 

NUMBER BYTES OBJECT COOE : 1912 



LOCAL 


VARIABLES : 






i 


j 




k 


1 




m 




GLOBAL 


VARIABLES : 






accht 


acc ke 




accms 1 


addon 




dgn v 


h t . mo v 




ke . mo v 


t a r d i m 


CALLED 


BY : 






main 





COMPLEXITY : Constant execution time and 

regu i remen t s . 

REMARKS : Combine 7 "for" loops with i = 1 to 2 into 



s t o r age 
i 1 1 cut 



storage 

loop. 
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RES5 



NUMBER BYTES OBJECT CODE : a8 

CALLED BY : 

ma i n 

REMARKS : This routine does nothing. 

SECTOR. CHECK 

NUMBER BYTES OBJECT CODE : 608 

PARAMETERS : 



LOCAL VARIABLES : 
a 
b 

c . r i gh t 
x . t 

GLOBAL VARIABLES : 
area 

x .current 



CALLS : 



abs . f 



CALLED BY : 



i mpac t 



answer 
c . 1 ef t 
r 

y . t 



constant 
y .current 



sqr t . f 



step, t i me 



COMPLEXITY : Constant storaae and execution time. 

SET. MUZZLE. VEL 

NUMBER BYTES OBJECT CODE : 400 



PARAMETERS : 
a 

LOCAL VARIABLES : 
a 

GLOBAL VARIABLES : 
mz 1 . ve ) 

CALLED BY : 

fire 

COMPLEXITY : Constant storage and execution time. 
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SET. SECTOR 



PARAMETERS : 

tank 

LOCAL VARIABLES : 
a 

tank 

x 

GLOBAL VARIABLES : 
pi .c 



NUMBER BYTES OBJECT CODE 



b 

width 

y 



CALLS : 

cos.f sin.f 

CALLED BY : 

c hg . sec . sea rc h defend 

di smount .dragon main 

red .create 
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COMPLEXITY : Constant storaae and execution time. 

SIGHT 

NUMBER BYTES OBJECT CODE : 712 



PARAMETERS : 





a 


aname 




b 


bname 


GL08AL 


VARIABLES : 






bwd .look 


f wd. 1 ook 




h t o 


micro 




name 


pc a . unc 




pc a . v i s 


ocb.unc 




pcb . v i s 


x .current 




y .cur rent 


z .current 


CALLS 


♦ 

• 






1 os 


m i n . f 


CALLED 


BY : 






commo .pass . tgt 


detect 




fire 


impact 




s t ep . t i me 


target .select 



COMPLEXITY : Constant storage and execution time. 
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STEP. TIME 



.NUMBER BYTES OBJECT CODE : 1664 



PARAMETERS : 
a 



LOCAL VARIABLES : 



a 


answer 


bdet .time 


1 ose 


r 


rde t . t i me 


rn . b 


rn . r 


GLOBAL VARIABLES : 


/ 


a 1 i ve . dead 


answer 


bud .look 


de f num 


de 1 t a . t 


f a 


f.blue.al ive 


f wd . 1 oo k 


name 


od . rng 


ocb.unc 


oc t . v i s 


steos 


t arget 


t qt sc 1 


t i m e . v 


w . k . c • 


x .current 


y.cur rent 

RESERVES : 

list 

RELEASES : 

1 i St 

CALLS : 


cardi o 


chg.sec .search 


di sr 


m i n . f 


sector .check 


sight 


t racer 


uni form. f 


SCHEDULES : 


detect 


s t eo . t i me 


SCHEDULED BY : 


main 


s t ep . t i me 


COMPLEXITY : Storage is constant. 


Execut ion time 


dependent on the number 


of tanks in red 



1 i near 1 y 
ive. 
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STOP. SIMULATION 



GLOBAL 



NUMBER BYTES OBJECT COOE : 4296 



VARIABLES : 

attributes of every 
attributes of every 
attributes of every 
attributes of every 
attributes of every 
a 1 i ve . dead 
aw 1 . o r . ms 1 3 
be .count 
c . 1 
co 

defnum 
f .d 

f i red . a t 
he .drag 
k . h i t 
1 i n 
m .d 

m f . h i t 
m k i 1 1 
name 

n . b 1 ue . a 1 i ve 

num . h i t 

pi t 

r . con 

sec 

spd 

t i me . v 
t . sod 
x .current 
z .current 



f o 

oa 1 1 e r y 
f dc 

mission in msn. queue 
mission in holdinq.msns 
ap . t ow 
bn 

'c.2 

erf 

dir.of.mvmt 
f . h i t 
fki 11 

hit. state 
k k i 1 1 

m . h i t 
mf k i 11 
mv . s t at e 
n d . h i t 
n.red.al ive 
o 1 ow.cond 
o r i . d i r 
rc .count 

tank 
t r f 

wpn.tyoe 
y. current 
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STOP. SIMULATION (cont) 



WRITES : 



CALLS : 

SCHEDULED 

COMPLEXITY 



attributes of 
attributes of 
attributes of 
attributes of 
at t r i butes of 
a 1 i ve .dead 
awl .or.msl 3 
be .count 



every fo 
every battery 
every fdc 
every mission 
every mission 
ap 
bn 



in msn .aueue 
in holding.msns 
tow 



c . 1 

CO 

def num 
f . d 

f i red. at 
he .drag 
k . h i t 
1 i n 



c . 2 
erf 

di r.of.mvmt 
f . h i t 
f k i 1 1 

hit. state 
k k i 1 1 



m . d 

mf • h i t 
mk i 1 ] 
name 

n. blue.al i ve 
num .hit 

p 1 t 
r . con 
sec 

SDd 

t i me . v 
t . sod 
x .cur rent 
z . c u r r e n t 



m . h i t 
m f k i 1 1 
mv. state 
nd . h i t 
n . red . a 1 i ve 
d 1 ow . cond 
Dr i . d i r 
rc .count 

tank 
t r f 

wpn . t yoe 
y. current 



1 oc 
BY : 

attrition. check main 

: Execution time is linear on tanks and 
i s constant . 



s t o r age 
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STOP. TO. FIRE . 



• NUMBER 


BYTES OBJECT CODE : 368 


PARAMETERS : 
a 


stopcount 


LOCAL VARIABLES : 
a 


s t opcoun t 


GLOBAL VARIABLES : 
o 1 ue 
p r o j o 
sod 
t . spd 


color 

second. shot 
't i m e . v 


CALLED BY : 

f i re 


i moact 


COMPLEXITY : Constant 

requ i rement s . 


execution time and storage 
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SUBCAL 



■NUMBER BYTES OBJECT CODE : 4040 



PARAMETERS : 





f . pcv i s 


DC.vis 




r 

tgt . t 


sh . t 


local 


VARIABLES : 






e f k i 11 


e f d ) 




e m k i 1 1 


emp ] 




f .pc v i s 


i 




i o 


') 




j o 


ka v k i 1 1 




k a y o 1 


] 




mo 


n 




nhit 


oc • v i s 




ph i t 


r 




ro 


sh . t 




tqt . t 
whoca 1 led 


ve 1 


GL08AL 


VARIABLES : 






bu shbmp 


damaqe .num 




dgn v 


oh 




P r o j o 


so vmg 




spd 


t a rd i m 




usmg 


wpn.tyoe 


WRITES 


* 

• 






pro j o 


won .type 


CALLS 


tA 

• 

• 






binomial . f 


bushbmp 




so vmg 
usmg 


t rune . f 


CALLED 


BY : 

compute 





COMPLEXITY : Execution time is linear on nhit and storage is 
constant . 
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T72. TACTICS 



NUMBER BYTES OBJECT COOE : 1216 



PARAMETERS : 
a 



LOCAL VARIABLES : 
a 

answer 
resul t 
x 



a i m 

lose 

time 



GLOBAL VARIABLES : 

a 1 i ve . dead 
chec k , t i me 
critical .value 
f wd . 1 ook 
p 1 1 1 dr 
sched 
t i me . a 



bwd . 1 oo k 
cocdr 
f oe 

pc t . v i s 
p r o j o 
'tank 
tiwe.v 



CALLS : 

ammo. check commo . pas s . t gt 

exp . f 1 ay . 1 oad 

1 oc 

CALLED BY : 

t arget .select 

SCHEDULES : 

fire 

COMPLEXITY : Execution time is linear on tank in pit. unit 
and storage requirements are constant. 



REMARKS 



Returns the value of answer to the 
routine. By initializing answer to 1 i 
Of two "if" sequences may be eliminatea 
in 11 fewer lines of source code. 



cal 1 i ng 
nstead of 
resul ting 
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TALLY. HIT. STATE 



NUMBER 8YTES OBJECT CODE : 1856 



PARAMETERS : 

damage. num tank 

LOCAL VARIABLES : 

damage. num tank 



GLOBAL VARIABLES : 





blue 


b 1 ue . a 1 i ve 






CO 


color 






comp.uni t 
f . h i t 


f i r ed . a t 






k . h i t 


list 






m . b 1 ue . a 1 i ve 


m f . h i t 






m . h i t 


name 






no . h i t 


num . h i t 






Pi t 


p 1 t . un i t 






red . a 1 i ve 


t a rge t 




REMOVES : 


tank f rom b 1 ue . 
Como .uni t 


alive or red. alive/ 


pit. unit and 


RELEASES : 


list 






CALLS : 


1 eave .chec k 






CALLED BY 


• 

• 








final .deat h 


impact 




complexity 


: Const ant 


execution time 


and storage 




reau i remen t s . 







TARGET. SELECT . 



NUMBER BYTES OBJECT CODE : 2592 



PARAMETERS : 
a 



LOCAL VARIABLES : 
a 

answer 

i 

old. range 
P 

rnd 

w hoc a 1 led 



a i m 

engaged 
i d 

o 1 dp 
r 

time 

x 



GLOBAL VARIABLES : 

a 1 i ve . dead 
bwd . I ook 
color 
defnum 
f i P 

f ki 1 1 
f wd . 1 ook 
list 
name 
pointer 
range 
target 
t i m e . v 
x. current 

CALLS : 

bmp . t ac t i c s 
di st 
h i d e r 

i tv . tact i cs 
list .update 
priori ty. and. round 
t72. tactics 



blue 

c h ec k . t i me 
critical .value 
f a 

f i re 
f oe 

1 ine. of. sight. exists 

m v . s t a t e 

pc t . v i s 

pro j o 

sc hed 

t i me . a 

wpn.tyoe 

y. current 



d i m . f 
exo . f 

i fv. tactics 
1 ay . 1 oad 
1 oc 

select s i qh t 

xml. tactics 



SCHEDULES : 

fire 



SCHEDULED BY : 

list. update we. hit 

we . m i s s 



COMPLEXITY : Constant storage and execution time. 
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TRACER 



PARAMETERS : 
a 



. NUMBER BYTES OBJECT CODE : 304 



LOCAL VARIABLES : 
a 



GLOBAL VARIABLES : 
t i me . v 



tr.time 



WRITES : 

a 



t ime.v 



CALLED BY 



arty. impact 

busy.radio.net 

checking. guns. avai labi 1 i 

commo .at tempt 

ena . of. mission 

fa.tgt .error 

fire 

impact 

new. coordinate. system 
new. miss ion 
pa ramet ers 
red. arty.fi res 
uoda te. cluster 



art y . t i me 
ty 

detect 

error 

f dc .process i ng 
auns .firing 
m r 1 .impact 
new . 1 oc a t i on 
open.radio.net 
position. update 
step. time 



COMPLEXITY : Constant storage and execution time. 
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UPDATE. CLUSTER 



NUMBER BYTES OBJECT CODE : 2256 



PARAMETERS : 

i d . f o 



LOCAL VARIABLES : 

est i mate .o f . t i me 
i d . m i ss i on 
name. priori ty 
t i me . 1 



i d . f o 
m 

o r i .value 
t i me . 2 



GLOBAL VARIABLES : 



amt . ac 1 1 ve . msns 
busy 

1 ast .e 1 ustered 
max. number. of. mi ssions.oer.fo 
stated time.v 



amt.msns.fi red 

debug 

msn . t i me 



WRITES 



i d . f o 



time.v 



CALLS : 



arty . t i me 
new .location 
tracer 



doing. clusters 
new. mission 



SCHEDULED BY : 

fa. 2. main 



f o .not .busy 



COMPLEXITY : Constant storage and execution time 

VALS. FOR. CASE 

NUMBER BYTES OBJECT CODE : 712 



GLOBAL VARIABLES 
ba 

capds 
caseap 
cda 
cheat 
i n i t 



CALLED BY : 

ma i n 



bh 

case 

casehe 

cdh 

gun t ube 



COMPLEXITY : Constant storage and execution time. 



201 



WE. HIT 



NUMBER BYTES OBJECT CODE : 1328 



PARAMETERS : 
a 



LOCAL VARIABLES : 
a 

GLOBAL VARIABLES : 



CALLS : 
CALLED BY 
SCHEDULES 



ao.tow 
aw2 . o r . adm 
c . 2 
foe 

hi t shot 
r.con 
won .type 



h i de r 



i mpac t 



n i de 



awl .or.msl 3 
c . 1 

de f num 
he . drag 
mi ssshot 
p .count 



target .sel ect 



COMPLEXITY 



Constant storage and execution time. 
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WE. MISS 



NUMBER BYTES OBJECT CODE : 1808 



PARAMETERS : 
a 

LOCAL VARIABLES : 

a answer 

r time 

x 



GLOBAL VARIABLES : 





ap . t ow 


✓ aw 1 .or .ms 1 3 




aw2 . o r . adm 


c . 1 




c . 2 


check. time 




de f num 


foe 




he .drag 


h i t shot 




m i ssshot 


pro j o 




range 


r.con 




sched 


t i me . a 




t iue.v 


won . t ype 




x .current 


y . c u r r en t 


CALLS : 




ammo .chec k 


d i s t 




exp . f 
1 ay . 1 oad 


h i der 


CALLED BY 


• 

• 

impact 




SCHEDULES 


• 

* 






fire- 

target .select 


hide 



COMPLEXITY : Constant storage and execution time. 
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XM1 .TACTICS 



NUMBER BYTES OBJECT CODE : 



PARAMETERS : 



LOCAL VARIABLES : 
a 
b 

GLOBAL VARIABLES : 
foe 

p 1 t . un i t 

CALLS : 

un i f o rm . f 



b 



answer 

z 



D 1 t 
tank 



CALLED BY : 

target .sel ect 

COMPLEXITY : Storage is constant. Execution 
dependent on the number of tanks in 
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352 



is linearly 
1 t . u n i t . 



APPENDIX C 



ROUTINE 



main 

h i de r 

res 1 

res2 

res3 

res4 

res5 

red . c rea t e 
b I .create 
new . forces 
sight 

convert .back 
param .set 
basic. load 
val s. for. case 
re I oad 
bug .check 
dr .mount 
dismount .dragon 
d f . c hg 
defend 
st ep . t i me 



LINES START 



SIMSCRIPT ROUTINES 



95 


ba028 


10 


- bb750 


3 


bb890 


2a 


bb9 7 8 


37 


be 148 


18 


bce50 


2 


bd5c 8 


43 


bd5 f 8 


46 


bdf 60 


5 


bea68 


9 


bebefl 


1 7 


beebO 


21 


b f 1 78 


27 


b f 5 1 0 


10 


b f d38 


40 


cOOOO 


12 


cOabO 


18 


c OebO 


12 


c 1358 


14 


c 1640 


12 


c 1830 


65 


c 1 aeO 



END 


BYTES 


bb750 


5928 


bb890 


320 


bb978 


232 


be 148 


2000 


bce50 


3336 


bd5c 8 


1912 


bd5 f 8 


48 


bdf 60 


2408 


bea68 


2824 


bebe8 


128 


beebO 


712 


bf 1 78 


7 12 


b f 5 1 0 


920 


bf d38 


2088 


cOOOO 


712 


cOabO 


2736 


c 0 eb 0 


1024 


c 1358 


1192 


c 1640 


744 


c 1 830 


496 


c 1 aeO 


688 


c 2660 


1664 
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ROUTINE 

detect 

t a rget .select 
fire 

1 eave.check 

charge 

get . uo 

i mpac t 

1 oc . upda t e 

st op. simulation 

c a r d i o 

list, update 

prox i m i t y .det ec t 

commo .pass.tgt 

t72. tactics 

ifv. tactics — 

xml. tactics 

bmp .tactics 

i tv. tactics 

set .muzz 1 e.vel 

priori ty. and. round. sel ect 

ammo .check 

decrement .ammo 

we .mi ss 

w e . h i t 

stop.to.fi re 



START 


END 


BYTES 


c2660 


c2978 


792 


c 29 78 


c 3398 


2592 


c 3398 


c 3c50 


2232 


c3c50 


C6278 


9768 


c 62 78 


c 6aeO 


2152 


c 6 a e 0 


c 6d20 


576 


c 6d2 0 


c 7ea8 


4488 


c 7ea8 


c 8028 


384 


c8028 


c 9 0 f 0 


4296 


c 90 f 0 


c 95 f 0 


1280 


C 95f 0 


c9d20 


1840 


c 9d2 0 


c a080 


864 


ca080 


c a2b8 


488 


c a2b8 


ca778 


1216 


ca778 


c a8d8 


352 


c a8d8 


caa38 


352 


caa38 


cab40 


264 


cab40 


cacaO 


96 


cacaO 


cae30 


400 


cae30 


cb368 


1336 


cb 368 


cb558 


496 


cb558 


cb858 


7o8 


cb858 


cb f b8 


1 808 


cb f b8 


cc 4e8 


1328 


cc4e8 


cc 658 


368 


cc 658 


ccea8 


2136 



LINES 

21 

7a 

51 

112 

a7 

12 

89 

6 

27 

55 

62 

26 

21 

27 

9 

9 

6 

9 

8 

49 

1 1 

13 

39 

28 

13 

35 



1 ay . 1 oad 



ROUTINE 

f i r s t 
h i de 
1 oc 

chg. sec . search 
tall y. hi t .state 
di st 

set . sector 

sector .check 

attri tion. check 

compute 

geom 

suoc a 1 

a t r i t 

pop .a . m i ne 

final .deat h 

fa. 1. main 

fa. 2. main 

f o .not .busy 

update .cluster 

commo . at t empt 

open .radio.net 

busy.radio.net 

f dc . process i ng 

checking. guns. avai labi 1 i ty 

guns . f i r i ng 

arty. impact 



start 


END 


BYTES 


ccea8 


cc f c8 


288 


cc f c8 


cd4c 8 


1536 


cd4c8 


cd q 1 0 


1096 


cd9 1 0 


cde28 


1304 


cde28 


ce5b8 


1856 


c e 5 6 8 


ce5f 8 


1 44 


ce5 f 8 


c e7b8 


448 


ce7b8 


cea 1 8 


608 


cea 1 8 


cec08 


496 


cec 08 


c f 9c 8 


3528 


c f 9 C 8 


d 1 958 


8080 


d 1 958 


62120 


4040 


d2720 


62 i fO 


2256 


d2f f 0 


d36d0 


1 760 


d36d0 


die 60 


14^4 


d3c 60 


d4 f a8 


4936 


d4f a8 


d5d38 


3472 


d5d38 


d5fd0 


408 


d5 f dO 


d64a0 


2256 


d64a0 


d68e8 


1 096 


do8e8 


d69g8 


240 


d69d8 


d6ac 8 


240 


d6ac 8 


d7828 


3424 


d7828 


d7 f 48 


1824 


d7f 48 


d8630 


1768 


d9630 


d9b50 


1312 



LINES 

5 

23 

23 

25 

4 3 

a 

12 

10 

7 

91 

150 

79 

43 

20 

14 

83 

44 

9 

46 

26 

6 

6 

1 10 

37 

34 

1 32 
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ROUTINE 


LINES 


START 


END 


BYTES 


end. of •mi ss i on 


59 


d9b50 


da5e0 


2704 


doi ng.c 1 ust ers 


1 14 


da5e0 


db998 


5048 


assessment 


95 


db998 


dcb48 


4528 


error 


28 


dcb48 


dc e f 8 


944 


red .arty.fi res 


75 


dc e f 8 


ddc20 


3368 


new.coordi nate.system 


8 


ddc20 


ddd 1 8 


88 


new.mi ssion 


27 


ddd 1 8 


de2b0 


1432 


parameters 


33 


de2b0 


de7 1 8 


1128 


a r t y . t i me 


24 


de7 1 8 


de8b8 


416 


f a • t g t .error 


21 


de0b8 


dea50 


416 


new. location 


54 


dea58 


de f c 0 


1384 


m r 1 . i mpac t 


53 


def cO 


df 9 C 8 


2568 


prep 1 anned 


31 


df9 c 8 


dfdb8 


1008 


pos i t i on .update 


29 


df db8 


e0208 


1104 


print 


10 


e0208 


eO 358 


336 


p r i n t 1 


22 


e0358 


e0840 


1124 


t r ac e r 


8 


e0840 


e09 7 0 


304 


new . f o 


8 


e0970 


eOb 38 


456 




FORTRAN ROUTINES 






move 


1 45 


e4c88 


e5860 


4048 


i n i t rd 


73 


eOe 1 8 


e 1 688 


2414 


setup 


53 


e70b8 


e7508 


1300 


1 os 


251 


e3260 


e4c88 


7504 


kover 


14 


ee220 


ee 3 f 0 


684 


e 1 ev 


33 


e2ea0 


e3 1 afl 


988 


aytunx 


31 


e f a 1 8 


e f aa 0 


1 1 38 
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ROUTINE 


LINES 


START 


END 


BYTES 


e 1 e vg 


38 


eebeQ 


ee f 78 


1132 


mcov 


2a 


e2b88 


e2dd8 


866 



PROGRAM TOTALS 






3842 ba028 


1 1 77e0 


382904 
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APPENDIX D 



ROUTINE 


TYPE 


WDS 


dgn v 


i 


16 


usmq 


i 


48 


so vmg 


i 


96 


bus hbmp 


i 


128 


accms 1 


r 


224 


k e . mo v 


r 


420 


accke 


r 


168 


h t • mo v 


r 


420 


acch t 


r 


224 


addon 


r 


80 


accbm 


r 


84 


bm . mo v 


r 


210 


t a rd i m 


r 


198 


hno rm 


r 


1000 


no r seed 


r 


2 


m i n 1 et h 




5 


tgt .acq. error 


r 


12 


t gt sc 1 


r 


18 


mu 


r 


24 


x.ct 


r 


2 


• 

O 

rt 


r 


2 


z . c t 


r 


2 


v . ms 


r 


2 



OPT 


REMARK 


TOTAL 


OPTIMAL 


3 


( */2 ) 


19 


19 


16 


(*/2) 


64 


64 


33 

/ 


( */2 ) 


129 


129 


47 


(*/2) 


125 


125 


23 




259 


247 


39 




503 


459 


19 




219 


187 


39 




503 


459 


23 




291 


24 7 


7 




87 


87 


9 




109 


93 


19 




251 


229 


10 




208 


208 


1 




1001 


1001 


0 




3 


2 


9 




15 


14 


3 




15 


15 


1 




19 


19 


3 




27 


27 


0 




3 


2 


0 




3 


2 


0 




3 


2 


0 




3 


2 



PTRS 

3 

16 

33 

47 

35 

83 

51 

83 

67 

7 

25 

41 

10 

1 

1 

1 0 

3 

1 

3 

1 

1 

1 

1 
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ROUTINE 


TYPE 


wos 


PTRS 


OPT 


REMARK 


total 


optimal 


c.bar 


r 


2 


1 


0 




3 


2 


p 1 . c 


i 


1 


1 


0 




2 


1 


m . det 


i 


1 


1 


0 




2 


1 


d • num 


i 


1 


1 


0 




2 


1 


p.hat 


r 


2 


1 


- 0 

/ 




3 


2 


pca.vi s 


r 


2 


1 


0 




3 


2 


pcb . unc 


r 


2 


1 


0 




3 


2 


pcb .vis 


r 


2 


1 


0 




3 


2 


pc a . unc 


r 


2 


1 


0 




3 


2 


P. V 


r 


2 


1 


0 




3 


2 


zh 


r 


2 


1 


0 




3 


2 


list 


i 


1 


1 


0 




2 


1 


t arget 


i 


6a2 


322 


3 




964 


645 


t emp . t a rge t 


i 


150 


1 


1 




151 


151 


ds 1 


i 


360 


16 


16 




376 


376 


as2 


i 


362 


10 


10 




372 


372 


t .dead 




1 


1 


0 


0/4 ) 


2 


1 


i .dead 


i 


1 


1 


0 


( * / a ) 


2 


1 


i t .dead 


i 


1 


1 


0 


0/4) 


2 


1 


1 el 1 


i 


ia70 


1 165 


691 


( * / a ) 


2635 


2161 


1 e 7 1 


i 


3675 


2911 


1659 


C * / a ) 


6586 


5334 


1 el2 


i 


210 


1 o 7 


8a 


( * / a ) 


377 


294 


1 e 72 


i 


525 


a 16 


249 


0/4 ) 


941 


774 


1 e 3 1 


i 


210 


167 


8a 


0/4 ) 


377 


294 


1 e61 


i 


210 


167 


8a 


0/4 ) 


377 


294 
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ROUTINE 


TYPE WOS 


PTRS 


OPT 


REMARK 


TOTAL 


OPTIMAL 


le81 


i 525 


a 16 


249 


( */4 ) 


944 


774 


1 e63 


i 525 


416 


249 


( * / 4 ) 


944 


774 
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